more multithread unsafe stuff

[Dean Gaudet <dg...@arctic.org>]

The following functions are thread unsafe, and we use them (some of them
in core code, like in main/util.c): 

ctime
asctime
localtime
gmtime
strtok

Now, it depends on how the win32 libc is implemented... those could be
implemented using thread-specific data, and be semi-safe.  I suspect that
must be the case, because we use them in such core code that you win32
folks would surely have seen some insanity by now.  If they're implemented
using thread-specific data it just means you can't pass the pointers
returned to different threads... 

We could use a file like this to prevent the accidental use of routines
that aren't thread safe.  But not until the code is rewritten to avoid
them. 

Dean

cat >os/win32/unsafe.c <<EOF
/* this doesn't exist, and if unsafe.o is ever linked into the app
 * it will cause a link-time error.
 */
extern int use_of_unsafe_threaded_function; 

int ctime(void) { return use_of_unsafe_threaded_function; }
int asctime(void) { return use_of_unsafe_threaded_function; }
int localtime(void) { return use_of_unsafe_threaded_function; }
int gmtime(void) { return use_of_unsafe_threaded_function; }
int strtok(void) { return use_of_unsafe_threaded_function; }
int tmpnam(void) { return use_of_unsafe_threaded_function; }
EOF

Re: more multithread unsafe stuff

[Paul Sutton <pa...@eu.c2.net>]

On Fri, 19 Dec 1997, Dean Gaudet wrote:
> The following functions are thread unsafe, and we use them (some of them
> in core code, like in main/util.c): 
> 
> ctime
> asctime
> localtime
> gmtime
> strtok

All C runtime lib calls are threadsafe on Win32, as far as I know,
provided you link with the MT import library (which we do). 

//pcs

Re: more multithread unsafe stuff

[Shane Caraveo <sh...@caraveo.com>]

> The following functions are thread unsafe, and we use them (some of them
> in core code, like in main/util.c): 
> 
> ctime
> asctime
> localtime
> gmtime
> strtok

Well, one thing m$ did do was make thread safe libraries to compile 
against.  Why?  Because if they didn't, none of their own software 
would work...oh god, what am I saying?!?!?!

Anyway, recently read up on strtok myself, because I had questioned 
the thread safeness of it.  It IS safe between threads, but not 
"within" a thread.  ie. if you call strtok on string a, then strtok 
on string b, then strtok on string a again, you'll get messed up 
results, which I think is normal anyway.  But if two threads are 
calling strtok at the same time, no problem. The static variable used 
for strtok is allocated per thread.

Here's more on the other functions.  There is NO reference as to 
wether the static variable for the time functions is allocated per 
thread, so these may be a problem, but based on the fact that I have 
had no problems running php (cgi) under apache on nt doing dbm and 
odbc accesses, and using calls to some of these functions in php, I 
think they are probably also allocated per thread.  I've run into no 
weird thread problems so far.  (Im on b3 still)

The gmtime, mktime, and localtime functions use the same single,
statically allocated structure to hold their results. Each call to one
of these functions destroys the result of any previous call. 

A call to ctime modifies the single statically allocated buffer used
by the gmtime and localtime functions. Each call to one of these
routines destroys the result of the previous call. ctime shares a
static buffer with the asctime function. Thus, a call to ctime
destroys the results of any previous call to asctime, localtime, or
gmtime.

re: more multithread unsafe stuff

[Ben Hyde <bh...@gensym.com>]

> The following functions are thread unsafe, and we use them (some of them
> in core code, like in main/util.c): 
> 
> ctime
...
> strtok

Oh these too
  gethostbyname
  gethostbyaddr 
     will it never end?

> Now, it depends on how the win32 libc is implemented... 

These happen to allocate thread local storage on Windows.

Oh my ... I see clib_mutex comming.

 - ben h.