Re: [boost] Presentation of Boost.Process (SoC project)

From: Julio M. Merino Vidal (jmmv84_at_[hidden])
Date: 2006-08-21 12:16:42

On 8/18/06, Sebastian Redl <sebastian.redl_at_[hidden]> wrote:
>
> On Fri, August 18, 2006 12:15 pm, JOAQUIN LOPEZ MU?Z wrote:
> >
> > 1. The lib provides functionality to spawn child processes and
> > examine them through launcher and child classes, respectively. Yet, it
> > seems to lack functionality to examine the *current* process. In
> > particular, it looks like one cannot get the handle_type of the current
> > process (Win32:GetCurrentProcessID) in a manner compatible with
> > child::get_handle.
>
> I agree. What I would also like to see is a good method of manipulating
> the environment variables of the current process. Sure, there's getenv(),
> but it's not exactly a great interface, and there is no portable way of
> setting one.

Hmm... but does that belong to this library?  It is easy to do by
introducing a new class that represents the current process.  Also, is
it really a good idea to change the current process' environment?  I
like how Boost.Filesystem's "forbids" to change the current working
directory very much, and environment variables seem very similar to
this.

> But basically, when I pass environment variables to a child, I might want
> to make them a modified version of the current environment, and for that
> I'd expect the library to provide a way to access current variables.

Some changes can be made to accomodate this.  E.g., having a
get_environment(var) method in the launcher.  Not very elegant at
first sight, though.

Or... decouple the environment from the launcher, make it an
independent (and public class) which you can instantiate (creating a
snapshot of the current values), modify and pass to a new process:

bp::environment e;
e.set("var", e.get("var") + foo);
bp::launcher l;
l.set_environment(e);

(Turning the launcher's start method into a free function and making
the launcher simply the process' execution "context" as somebody else
suggested gives a lot more room for improvement here.)

> > 2. Would it be safe to guarantee that handle_type is an
> > integral type? It is so at least for POSIX and Win32. This would allow the
> > programmer to output handle_type's to std::ostreams's (for tracing
> > purposes, for instance) and to use handle_type's in a number of scenarios,
> > vg to store them in STL data structures.
>
> Win32's HANDLE is a pointer type. Does that count as integral?

I don't think so.  You cannot treat it as an integer in all cases
without casts.  But see my reply to Joaquín; HANDLEs are most probably
used as identifiers when they really shouldn't be.

> Excellent work on the library, all in all.

Thanks :)

-- 
Julio M. Merino Vidal <jmmv84_at_[hidden]>
The Julipedia - http://julipedia.blogspot.com/