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: Oliver Kowalke (k-oli_at_[hidden])
Date: 2011-02-14 20:07:25

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.