🚀 go-pugleaf

In article <DENS.92Jul31223733@flammulated.rice.edu> dens@flammulated.rice.edu (Dennis Allen Schmitz) writes:

   I am told that they are reentrant, but not thread safe. Exactly how
   this can be so escapes me, but I'm not going to use libraries in
   multiple threaded routines unless I trace the source first.

It is my understanding that all that being "reentrant" here means is
that the work space used by a function is allocated on the stack, so
that if one thread is blocked in the middle of function call to, say,
sprintf(), and a second thread also calls sprintf() before the first
thread runs again, then the local variables needed by sprintf() are
freshly allocated on the second thread's stack, and those used by
the blocked thread for its call are not clobbered by the second
call. If, on the other hand, a sprintf() implementation used a hidden
static data area for workspace for some operations, as some implementations
do for formatting floating point numbers, then the second thread's call
could clobber the first thread's data with unpleasant results.

Now, if our two threads were both to call printf() (or fprintf() with
the same file pointer), then separate stack spaces and no global
variables are not enough, unless access to, say, stdout, is serialized
using a semaphore or something of the sort. The output from the call
by the second thread will wind up in the middle of that from the first
thread. To be thread safe, then, requires that printf() allocate a
semaphore (on the first call; if it lives in a DLL it gets more
complicated) to serialize access to stdout, and would mean, in our
example, that the second thread would be blocked on that semaphore
until the first had finished its printf() call and relinquished the
common resource.

Since most UNIX implementations do not have multi-threading, no
support for such is built into the generic routines used in glibc. On
the other hand, it is my understanding that the GNU kernel (which
will, some day, be a released reality...) will support multi-threading
and so, perhaps some future port of glibc to OS/2 could the more
easily add this. At present, though, it would take rather a lot of work...

Hope this explanation is not too pendantic (well, I am paid
to teach :-).

Paul Lyon