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:53:52

Jeremy Maitin-Shepard wrote:
>
> The POSIX extension interface is quite powerful, to the point
> that there should be little need to bypass boost.process, while
> the Windows extension interface is not very powerful at all,
> only providing access to a small subset of the many options
> available.  It is also the case, though, that in many ways
> process creation through the Windows API is much more
> straightforward than process creation through the POSIX API,
> and therefore the abstraction provided by a library like
> Boost.Process is less critical on Windows, particularly for
> advanced uses. Potentially there could be two different
> extension interfaces on Windows, with the basic one similar to
> the existing one except for maybe allowing a few additional
> flags to be specified, and the advanced one could be fully
> general by allowing the user to call an alternate API function
> like CreateProcessWithLoginW, and users that don't need this
> level of control could simply ignore it.

In these particular cases, anyway, the issue is which function to
call and which options to provide to create the child process.
The function that triggers that behavior could be overloaded such
that the caller can supply a callback to invoke that returns a
handle to the new process.  Boost.Process could supply arguments
to the callback to indicate which options must be used when
creating the new process and it would be the caller's
responsibility to supply a well-behaved callback that creates a
process with the attributes required by Boost.Process.

Thus, in the normal case, Boost.Process creates the child process
in the usual way, with no callback, but in custom use cases, the
client supplies a callback to invoke a different API or to
specify options Boost.Process wouldn't ordinarily specify.
Boost.Process is at the mercy of the caller to do the right
thing, but it is clean and does make possible platform-specific
customization.

Obviously, this same approach is possible for other customization
points.

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