Re: [boost] [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]

Subject: Re: [boost] [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2011-02-14 20:44:47

On 02/14/2011 05:07 PM, Oliver Kowalke wrote:
> Am 14.02.2011 22:51, schrieb Jeremy Maitin-Shepard:
>>> maybe you misunderstood my concerns.
>>> as I wrote in my previous posts - we have two possibilities in a
>>> multi-threaded env.:
>>>
>>> 1.) for each child process a thread is created calling waitpid() with
>>> the pid of the forked process only and returning the child state via a
>>> future
>>>
>>> 2.) only one thread is created dealing with the status of child
>>> processes - it calls sigwait() with SIGCHLD unblocked and waitpid(-1, &
>>> status, WNOHANG | WUNTRACED | WCONTINUED) until waitpid() returns ECHILD
>>>
>>> I've some concerns if boost.process would implement the second point
>>> because it is a subset of the functionality of a boost library dealing
>>> with delivered signals (as SIGUSR1, etc.).
>>
>> There is a third possibility, which is what I was referring to in my
>> previous message: no additional threads are created to handle SIGCHLD
>> and instead SIGCHLD is handled in any thread that does not block it (the
>> user is expected to leave it unblocked in at least one thread).
>>
>> This would have the lowest overhead, I believe, and therefore be the
>> best option to use, and it also would not require any coordination as
>> far as signal handling with the rest of the program (but of course would
>> require coordination as far as waitpid), except that it will manage
>> SIGCHLD (but monopolizing SIGCHLD and calling waitpid go hand in hand).
>
> The SIGCHLD signal would be delivered to only one of the threads and you
> don't know to which one. you would have to install in all threads the
> same code.

Yes, it would be delivered to an arbitrary thread, but as signal handler 
settings are shared between threads, it would only be necessary to call 
signal/sigaction once.