Re: [non-stop] 08/10 linux native support

[Michael Snyder <msnyder at specifix dot com>]

On Tue, 2008-07-08 at 23:47 -0400, Daniel Jacobowitz wrote:
> On Tue, Jul 08, 2008 at 08:25:36PM -0700, Michael Snyder wrote:
> > Fork is undefined in a multi-threaded program.
> 
> According to what?  Not POSIX - otherwise there wouldn't be
> pthread_atfork.
> 
> I think even vfork is valid in multithreaded programs; in any case, it
> behaves sensibly with NPTL.

Well, I should perhaps say for, is *not well* defined in a
 multi-threaded
program -- at least not defined consistently.  I had to research this
at my last job but one, and it was very difficult to find anything that
definitively says that it is UN-defined... but try to find Posix
explicitly saying what *should* happen if a multi-threaded program 
forks.


Here's IEEE std 1003.1:

A process shall be created with a single thread. If a multi-threaded
process calls fork(), the new process shall contain a replica of the
calling thread and its entire address space, possibly including the
states of mutexes and other resources. Consequently, to avoid errors,
the child process may only execute async-signal-safe operations until
such time as one of the exec functions is called. [THR] [Option Start]
 Fork handlers may be established by means of the pthread_atfork()
function in order to maintain application invariants across fork()
calls. [Option End]


The issue is that only the thread that actually calls fork()
will be duplicated in the child, but the mutexes (which may have
been held by another thread) will be duplicated, and therefore
the child may deadlock.