Subject: Re: [boost] [gsoc] Boost.Process done
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2010-09-10 18:02:38
On 09/10/2010 02:25 PM, Ilya Sokolov wrote:
> On Thu, 09 Sep 2010 18:25:57 -0700
> Jeremy Maitin-Shepard<jeremy_at_[hidden]> wrote:
>> On 08/30/2010 11:59 AM, Boris Schaeling wrote:
>> > [snip]
>>> I checked now why I even had to add -lpthread if it wasn't required
>>> in earlier Boost.Process drafts: The new status class uses a worker
>>> thread to support asynchronous I/O. So yes, threading=multi is the
>>> natural choice. ;) Updated in SVN and in the ZIP file.
>> The use of a worker thread seems like an unfortunate additional
>> burden. I don't know about the Windows implementation, but on Linux
>> it seems in principle it should be possible to handle it via a
>> SIGCHLD handler.
> Callback would need to be async-signal-safe. If a user worries about
> performance so much, she could set up signal handler itself.
The user's own logic doesn't need to happen in the signal handler ---
the signal handler can just take care of alerting asio to the event, so
that it can then be processed later. Pipes are a standard way of
implementing the communication. (Probably it would make sense to
implement signal handling support as a general asio facility.)
There is, of course, the general problem that setting a signal handler
involves changing the global program state, and so it needs to be
coordinated to some extent with the rest of the program. At the low
level, it is probably useful for the user to be able to specify
additional callback functions that will serve as additional signal
handlers invoked by the boost-specified signal handler. Additionally,
though, if there are a bunch of sub-processes, it would be inefficient
to separately call waitpid for each of their pids in order to determine
which, if any, caused the signal. It would be preferable, instead, to
invoke waitpid/waitid with a pid of -1 to check all child processes.
This, however, requires coordination with any other code that deals with
child processes, since if waiting returns a pid not managed by boost
process, some other code likely needs to be notified.
Given the name boost.process, though, it doesn't seem unreasonable for
the library to take responsibility for all of this. Obviously, this is
a rather annoying complication compared to what is required for Windows,
but it seems like the only efficient option.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk