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

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

Boris Schaeling wrote:
> On Fri, 10 Sep 2010 05:02:54 +0200, Jeremy Maitin-Shepard
> <jeremy_at_[hidden]> wrote:
>
> > Furthermore, it seems inconsistent that certain things are
> > part of the "reusable" context, like the environment and
> > process_name, but other things, like the executable path and
> > arguments, are not.
>
> So far reusing a context means launching the very same
> application a second time. This didn't work first with the
> stream behavior class hierarchy but works now with the
> delegates.

Is there much demand for launching the same process repeatedly?
Even if so, that doesn't fit my idea of a "context."  To me,
"context" would capture things about the current process.  What
you've called "context" seems much more like "child_process" to
me.  Have I missed something?

> Once we start to support platform-specific features the
> question is where do we end? The context class in previous
> Boost.Process versions grew more and more as support for uid,
> euid, gid, eguid, chroot etc. was added. Instead of arguing
> about each and every feature whether it's justified to hardcode
> it into the library we decided it might be better to support
> cross-platform features only and provide extension points.

The answer to what should be included and not should be based, in
part, on how common the need proves to be.  That is, rather than
be biased against something because it isn't portable, consider
whether the library can be truly helpful.  Even if the feature is
unique to one platform, if the library can offer valuable support
for a feature used regularly on that platform, then supporting
that feature in a platform-specific namespace would be helpful.

Once you allow for platform-specific functionality, there can be
demands for a great deal that diverges wildly among the supported
platforms and leaves relatively little in the cross-platform
portion, so caution is still needed.  However, if much of the
platform-specific support is merely by providing hooks into the
library's behavior, such as the callback I suggested for creating
a process, then there shouldn't be too much need for
platform-specific functionality in the library.  That is, you can
allow such functionality but quite possibly preclude the need for
it via customization hooks.

The customization hook approach also leaves wide open what the
library client can do, provided it can be done within the
constraints of the interface provided.

> > - I think it would be cleaner for the POSIX and Windows
> > extension interfaces to be in the form of a callback function
> > (templated or boost::function), rather than a subclass of
> > context that overrides the setup function.
>
> Makes also sense to me!

Perhaps you both were thinking of what I've been suggested herein
and in my other reply, though I'm not quite certain.

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