> From: Mark H Weaver <m...@netris.org> > Cc: l...@gnu.org, guile-devel@gnu.org > Date: Sat, 22 Feb 2014 23:40:20 -0500 > > Eli Zaretskii <e...@gnu.org> writes: > > >> It's safe to fork a multithreaded program without using pthread_atfork > >> if only async-signal-safe functions are called before the exec. > > > > You may know what your code does between fork and exec, but you don't > > know what other parts do, like pthreads or the application that called > > Guile as a library. > > I'm not sure I understand what you mean here. The relevant code here is > between line 1366 (/* The child. */) and the call to execvp on line > 1408. I see calls to 'close', 'open', 'dup', and 'dup2'. > > How could "pthreads" or "the application that called Guile" cause > anything else to happen between fork and exec in the new single-thread > child process?
Pthreads could have locked some mutex before you fork, for example, in which case the child starts with a locked mutex and no live thread that will release it any time soon. The application could have done similar things, especially if it also uses threads, or some library that uses shared memory. Btw, I didn't write above anything that is not described here: http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html
