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 16:51:34

On 02/14/2011 01:26 PM, Oliver Kowalke wrote:
> Am 14.02.2011 22:02, schrieb Jeremy Maitin-Shepard:
>> On 02/14/2011 01:00 PM, Jeremy Maitin-Shepard wrote:
>>> On 02/14/2011 12:50 PM, Oliver Kowalke wrote:
>>>> Am 14.02.2011 21:14, schrieb Jeremy Maitin-Shepard:
>>>>> SIGCHLD handler will repeatedly invoke waitpid(-1, &status, WNOHANG |
>>>>> WUNTRACED | WCONTINUED), and then invoke any registered handlers.
>>>>
>>>> why polling - it waists CPU cycles?
>>>> I expect that the thread waiting for child processes state change
>>>> blocks
>>>> (gets suspended) until it is notified by the kernel that something has
>>>> happened.
>>>> other worker-thread do other stuff like communicating with other
>>>> process
>>>> etc.
>>>
>>> It wouldn't poll indefinitely, as that would lock up the thread in which
>>> the signal handler was invoked. It is simply invoked repeatedly until
>>> the error ECHILD (meaning no more unwaited-for children) is returned.
>>> The notification is in the form of SIGCHLD, but that just means one or
>>> more children need to be waited on.
>
> 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).