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 16:26:13

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.).