ri...@happyleptic.org 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/>