This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [non-stop] 08/10 linux native support
> 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.