Subject: Re: fork(2) vs. pthread_create() (fwd)
To: None <email@example.com>
From: Thor Lancelot Simon <firstname.lastname@example.org>
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
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 email@example.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