Re: [boost] [gsoc] Boost.Process done

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.