Re: open-pipe deadlocked

[Andreas Rottmann]

address@hidden writes:

> Hello !
>
> Sometime, my progam calls open-input-pipe and the forked child hangs
> waiting for a lock (so after the fork but before executing the command).
>
> So I read the code for open-process, especially what happens between the
> fork and the execlp, and I noticed several potential problems :
>
> - all ports are closed, but what about other open files that are not
>   ports ? My application opens many files in C that are not known to
>   guile. Shouldn't these be closed as well ?
>
>From this, I gather you have a C application that has Guile embedded,
right?  Or are you rather having a Guile application that uses
third-party C code via language bindings?  In the first case, it could
be a workable solution (since you control all the C code) to just open
all files with the FD_CLOEXEC flag set, assuming you don't want to share
these file descriptors with the child.  In the latter case, you are (in
general) a bit out of luck; perhaps this[0] LWN discussion can shed some
light on the general issue here.

[0] http://lwn.net/Articles/292559/

Personally, I think FD_CLOEXEC being set per default would be a good
thing, but that's not going to happen, so one can either keep track of
all FDs to close between fork() and exec(), or mark all FDs as
FD_CLOEXEC manually after their creation. However the former is not
possible with the current implementation of `open-process', as there's
no user-defined code being executed between fork() and exec() to do the
actual closing.

> - what if when forking some other guile thread hold one of the internal
>   lock (for instance, the lock protecting the port table) ? Then the
>   code between the fork and the exec (which loop on all ports, amongst
>   other things) may try to grab this internal mutex, deadlocking.
>
I've not yet done multithreading with Guile, but I think you are right;
Guile should use pthread_atfork() as explained at[1], but it apparently
does not (or at least so "git grep" indicated).  This sounds like a bug;
could you come up with an example program that has a good chance to run
into this suspected issue?

[1] http://pubs.opengroup.org/onlinepubs/007904975/functions/pthread_atfork.html

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>