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

Subject: Re: [boost] [gsoc] Boost.Process done
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-09-13 07:41:27

Jeremy Maitin-Shepard
> On 09/11/2010 01:47 PM, Boris Schaeling wrote:
>
> > There is only one worker thread within the ioservice object.
>
> I assumed you were using waitpid with the specific pid of the
> child, but I just took a look at the code and see that you are
> using wait (which waits for any child, equivalent to waitpid
> with a pid of -1).  This indeed avoids the need for one thread
> per child process, but has the serious drawback that it will
> silently eat all notifications related to child processes not
> created by boost process, and therefore prevents any other code
> in the same program from properly dealing with child processes.

That's definitely bad behavior and must be avoided.

> Note that from a SIGCHLD handler, you could invoke waitpid with
> WNOHANG once for each child process, and this way avoid the
> need to coordinate regarding child process notification, but
> you would still need to coordinate regarding SIGCHLD, and I
> think it would be very inefficient to have to make one syscall
> per child process each time SIGCHLD arrives.

Is not signal handling a process-specific behavior?  It may be
POSIX-specific, but it seems reasonable that Boost.Process
provide signal handling support.  Then, Boost.Process can require
that all code in a process using that library must coordinate
with its signal handling.

If Boost.Process provides useful and convenient support for
signal handling, most users of the library would use that for
their signal handling.  Those that must integrate with other
signal handling code need only have some means of tying both
together.

I have code for doing such convenient signal handling that I
think I could get permission to share if you're interested.  It
would, at least, be a good jump start.

> If you arranged to have all of the child processes created by
> boost process actually be grandchildren of the main process,
> and children of a special forked process created by
> boost.process, then you could simultaneously avoid coordination
> regarding SIGCHLD and waitpid, at the cost of just one
> additional process.  However, due to the need for an additional
> process, I don't really like this solution either.

That it behaves properly is an excellent recommendation for this
approach compared with wait().  I'm not sure that the overhead of
yet another process is an insuperable problem, but it is cause
for concern.  Still, if Boost.Process takes on signal handling
and requires that other signal handling code cooperate with it,
then SIGCHLD is made available and eliminates the need for the
interstitial process.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.