Re: [PATCH] Implement open-process and related functions on MinGW

[Mark H Weaver <mhw@netris.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mark H Weaver <mhw@netris.org>
>> Cc: ludo@gnu.org,  guile-devel@gnu.org
>> Date: Sat, 22 Feb 2014 23:40:20 -0500
>> 
>> Eli Zaretskii <eliz@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.

This is precisely why it's important to use only async-signal-safe
functions between fork and exec in the child process.  Such functions,
by contract, already have to cope with data structures (such as mutexes)
being in an inconsistent state that will never become consistent no
longer how long they wait, because the thread that has the mutex locked
(or is in the middle of locking/unlocking a mutex) might be the same
thread that the signal handler is running in.  They also cannot use
mutexes at all.

> The application could have done similar things, especially if it also
> uses threads, or some library that uses shared memory.

Any async-signal-safe function has to cope with this kind of thing, by
contract.

I don't know what else to say.  We have followed the widely recognized
guidelines for how fork+exec from a multithreaded program, as documented
in the POSIX spec and elsewhere.  If you still think there's a problem
here, please do the research and bring us something more specific, or
construct a test case that demonstrates a problem.

    Thanks,
      Mark