Subject: Re: Threading problems
To: Eric Haszlakiewicz <>
From: Bill Studenmund <>
List: tech-kern
Date: 11/23/2004 18:59:43
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 23, 2004 at 03:54:43PM -0600, Eric Haszlakiewicz wrote:
> The thread safe way will clearly be a lot slower than the current no-pthr=
> way.  For this particular example, I think the non-thread safe way would
> allow for the thread safe way to be switched in at any time.  The non-thr=
> safe way would be a little slower than the current way.  I'm assuming
> the other methods can be partially stubbed out in a similar fashion.
> So, the question is: for programs that use dlopen(), is the (smaller)
> performance hit a worthwhile tradeoff for allowing threaded libraries to
> be seamlessly loaded?  I think it probably is.

You're assuming you can get it totally right. I'm not saying you got the
part you described wrong, I'm saying that once we start down the path you=
describe, we will either end up fighting a lot of painful battles or we=20
will have to draw an arbitrary line & say we support only so much.

For instance, consider a library ported to NetBSD, where the porter=20
decided to use the threadlib facility to make the library work right if=20
it's in a threaded app and right if it isn't. After all, libc isn't the=20
only library that wants to do the right thing if threading is around even=
though it doesn't need threading itself. Further, while Nathan is correct=
that static initializers are fine (and libc uses them), it's perfectly=20
legit for a library to need malloc'd mutexes (or mutexes in malloc'd=20
things), so the init function needs to work.

Also, you're assuming that the program is fine being suddenly-threaded.=20
Say _it_ is built different if threads are enabled or not. Adding -pthread=
to the command line defines "_REENTRANT", which a program certainly can=20
use to change its behavior. Looking in stdio.h, its behavior will be=20
different. Some things it does will never be able to work right adding=20
threading later.

Given how much code really needs to be _REENTRANT or not at compile time,=
I don't see how we can ever make "magic add pthread later" work right. So=
I think what we're doing now is the right thing, by making it obvious the=
code needs recompiling.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)