| The interaction of thread-safe and nonthread-safe code within a process is
not precisely defined and, in particular, is not supported.
Sharing errno is one of the most visible problems, but not the only one. The
way the thread-safe errno interacts with the global errno has changed a few
times, and may change again. You appear to be running a version where setting
a thread's errno (by calling seterrno(), as libc does) also sets the global
errno. The problem with this is that a nonthreaded main program, running in
the default thread, is constantly barraged with asynchronous changes to errno
from all other threads that call libc. That makes errno essentially useless
for any code. In PTmin, the definition has changed so that only thread-safe
errno changes IN the main thread also set the global errno -- other threads
change only their private errno. This allows nonthread-safe code to run
undisturbed, potentially with thread-safe libraries, IN the main thread. You
cannot run nonthread-safe code in another thread (or if you do, you won't see
any changes to errno). This isn't entirely ideal, since it would be nice to
be able to reliably run nonthread-safe code in any ONE thread -- but I don't
see how that could be practical. (On the other hand, if someone DOES come up
with a better way, I'll happily change the code again.)
Other problems include symbol preemption concerns. This is much worse prior
to Digital UNIX 4.0, where all thread-safe code relied on libc_r and
libpthreads preempting libc symbols. If the main program was not linked
against libpthreads and libc_r, those shared libraries would be loaded at the
end of the symbol preemption pecking order, and the entire program would run
with the libc nonthread-safe versions. The situation is far better on 4.0,
because there's no libc_r, and libpthread doesn't preempt any libc symbols.
However, libpthread now uses libexc standard exception handling, and libexc
relies on preempting one critical symbol from libc. Thus, if the main program
wasn't linked with libexc, exception handling won't work. That includes the
implicit use of exceptions in all threaded programs -- like pthread_exit and
pthread_cancel.
/dave
|