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

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> From: Michael Snyder <msnyder@specifix.com>
> Date: Tue, 08 Jul 2008 20:55:06 -0700
> 
> 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.

And I'd argue that this is a direct logical consequence of the fact
that fork() behaviour is pretty well defined by POSIX.