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

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

Jeremy Maitin-Shepard wrote:
> On 09/13/2010 11:15 AM, Stewart, Robert wrote:
>
> > Hmmm.  As I see it, Boost.Process would know which child
> > processes it created and would only call waitpid() on those.  No
> > code outside the library would need to call waitpid() on those.
> > All that's needed is for Boost.Process' SIGCHLD handler to be
> > invoked and, if the other code needs a SIGCHLD handler, that it
> > be invoked by the same mechanism, to ensure correct chaining, and
> > that the other code never calls waitpid() for child processes
> > that Boost.Process creates.
> >
> > Is that what you meant by "specific coordination?"  That's not
> > coordination so much as clear delineation of responsibilities and
> > behaviors, but it would mean we were just talking past one
> > another.  If you meant something else, please clarify.
>
> If Boost.Process has created multiple not-yet-terminated child
> processes, you would need to call waitpid once for each child
> every time SIGCHLD arrives. This would not scale well to
> e.g. 200 child processes.
>
> Likewise, you cannot expect code outside of Boost.Process that
> deals with child processes to have to invoke waitpid in a
> polling fashion.  (I don't know what the actual overhead cost
> is, but in any case it doesn't seem reasonable.)

Indeed, calling waitpid() for each child, in turn, is not a good
idea from a scalability perspective.  Putting all of
Boost.Process' children into a unique process group and using
waitpid(), with WNOHANG, to wait for children in that process
group could work though.

If the client can control the process group of any child created
with Boost.Process, then the library can track the process groups
that have been specified and call waitpid() for each in turn.  If
the PID of the terminated child is not recognized, then, it must
have been created by other code in the process using one of the
process groups given to the library.  In that case, a callback
function would permit the library to inform the client that such
a child terminated.  That doesn't help when the client cannot
communicate such information to a third-party library that wants
SIGCHLD.  Sadly, even chaining SIGCHLD handlers won't help in
that case.

Here's another idea: if Boost.Process managed one child process
that itself actually created the children, and communicated their
creation and demise via pipe or socket, then that process can use
a SIGCHLD handler with impunity and Boost.Process, in the
grandparent process, will only be informed of the demise of
grandchildren created by the library.

Since creating a child process to manage grandchild processes is
heavier weight than the process group approach, but the latter
won't always work, perhaps the library could offer both options.

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