Subject: Re: fork(2) vs. pthread_create() (fwd)
To: None <tech-userlevel@netbsd.org>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-userlevel
Date: 06/08/2004 20:45:09
On Wed, Jun 09, 2004 at 12:17:11AM +0200, Emmanuel Dreyfus wrote:
> > Notably, none of the pthread_* functions are async-signal-safe.
> > 
> > In order for this to work, there would have to be a fork handler that
> > reset all of libpthread's state to initialization values, and the
> > child program would still suffer severe constraints on what program
> > mutexes or variables it could use (consider, for example, the state of
> > stdio mutexes at the moment of fork()).
> 
> I don't find this very satisfaying. Forking from a program that executed
> threads works on Linux and FreeBSD. It's not an extraordinary scenario.

FSVO "works".  I think it would be more accurate to say "is broken in a
more subtle way, which may deceive naive programmers into thinking that it
'works'".

Recall that Linux is theoretically moving (or has moved?  What is the
current state of affairs, with the latest glibc and kernel?) away from
the "every thread is a heavyweight process" model that would make this
most likely to appear convincingly to work (but still be very badly
broken in some corner cases).

-- 
 Thor Lancelot Simon	                                      tls@rek.tjls.com
   But as he knew no bad language, he had called him all the names of common
 objects that he could think of, and had screamed: "You lamp!  You towel!  You
 plate!" and so on.              --Sigmund Freud