On Wed, Mar 05, 2003 at 09:07:16PM +0000, David Laight wrote:
> > If you want to be able to dynamically load such code, even if
> > the main body of your program doesn't use threads, there is a simple way
> > to make it safe to do so: just link to libpthread in the first place and
> > it will all work fine.
> 
> I suspect this isn't always possible, all it takes is for some service
> the program uses to be implemented in a dlopen()ed library, and for that
> to need libpthread and you have a massive breakage!

But it's already the case, and is likely to always be the case unless the
stub synchronization/locking functions in libc are removed.  A program is
either singlethreaded or multithreaded, and we optimize for the common
case, which is "singlethreaded"; the only way to get the behaviour you want
would be to change the default to "multithreaded" and ship a libc_r or
the like that did not have the thread mutexes, etc.

The *only* significant negative consequence is that you can't dlopen()
libpthread and magically have libc become reentrant.  I don't think it's
an undue burden to impose, that code that wants to run multithreaded has
to *initialize* libc that way -- which means including libpthread on the
link line at compile time.

Thor