Boost logo

Boost :

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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at