Subject: Re: libpthread busted?
To: David Laight <firstname.lastname@example.org>
From: Thor Lancelot Simon <email@example.com>
Date: 03/05/2003 16:42:28
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.