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

[Mark H Weaver]

Eli Zaretskii <address@hidden> writes:

>> From: Mark H Weaver <address@hidden>
>> Cc: address@hidden,  address@hidden
>> Date: Sat, 22 Feb 2014 17:02:35 -0500
>> 
>> Eli Zaretskii <address@hidden> writes:
>> 
>> >> From: Mark H Weaver <address@hidden>
>> >> Cc: address@hidden (Ludovic Courtès),  address@hidden
>> >> Date: Sat, 22 Feb 2014 10:54:16 -0500
>> >> 
>> >> Thanks for working on this, but in a multithreaded program, it's no good
>> >> to change the file descriptors in the main program temporarily before
>> >> spawning, and then restore them afterwards.  We'll have to find another
>> >> way of doing this.
>> >
>> > Btw, how does the Posix build work reliably when it forks after
>> > several threads are already running?  I don't see any calls to
>> > pthread_atfork or any similar machinery in place.  What am I missing?
>> 
>> 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?

     Mark