On 09/10/2010 02:25 PM, Ilya Sokolov wrote:
On Thu, 09 Sep 2010 18:25:57 -0700 Jeremy Maitin-Shepard<jeremy@jeremyms.com> 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.