On Tue, Jun 08, 2004 at 09:56:26AM -0400, Nathan J. Williams wrote:
> tron@zhadum.de (Matthias Scheler) writes:
> 
> > I found out today that NetBSD's "libpthread" doesn't like it when an
> > application uses pthread_create(), fork() and finally pthread_create()
> > in the child process.
> 
> "don't do that".

That's what I guessed already. :-)

But the author wasn't too convinced because it works with several
other POSIX threads implementations.

> Notably, none of the pthread_* functions are async-signal-safe.

I see.

> 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()).

There is no such problem in this particular program. It creates a single
thread(*), waits until that thread exits, fork()s and creates more threads
later in the child process.

	Kind regards

(*) The whole reason is that it needs lots of stack space for a certain
    task. Because threaded applications don't get enough stack space
    by default e.g. under FreeBSD the programs creates a thread with
    2MB stack space to perform that task.

-- 
Matthias Scheler                                  http://scheler.de/~matthias/