[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: open-pipe deadlocked
From: |
Andreas Rottmann |
Subject: |
Re: open-pipe deadlocked |
Date: |
Tue, 02 Aug 2011 23:24:59 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
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/>
- Re: open-pipe deadlocked,
Andreas Rottmann <=