Eli Zaretskii <e...@gnu.org> writes:
>> From: Mark H Weaver <m...@netris.org>
>> Cc: l...@gnu.org, guile-devel@gnu.org
>> Date: Sat, 22 Feb 2014 17:02:35 -0500
>>
>> Eli Zaretskii <e...@gnu.org> writes:
>>
>> >> From: Mark H Weaver <m...@netris.org>
>> >> Cc: l...@gnu.org (Ludovic Courtès), guile-devel@gnu.org
>> >> 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
