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

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

On 8/18/06, JOAQUIN LOPEZ MU?Z <joaquin_at_[hidden]> wrote:
> Hello Julio,
>
> A cursory look at the docs shows this can be a very valuable
> contribution to Boost. Thank you for your effort!

You're welcome :-)

> Although I plan to give a thorough review during the next week,
> let me advance a few issues:
>
> 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. Would it be
> feasible to extend the lib to support this? In case it would,
> maybe it'd be a good idea then to rename "child" to a neutral
> "process", for instance, so that process classes are returned by
> laucher as well as by some potential "current_process" facility.

I started the project thinking on a library to manage children
processes as well as currently running ones (not only "self").  This
turns out to be very, very complex portability-wise, and so Jeff
convinced me to simplify it to child process management only.  Most of
the code used to support those ideas was not well thought and was
removed recently.

*However*, adding support for the specific feature you mention is
relatively easy.  I'd even say very easy.  The idea is to introduce a
new "process" class from which the existing "child" inherits.  The
parent could hold the identifier and provide additional functions such
as "kill".  This could let you do:

bp::process self = bp::get_current_process();
bp::child c = l.start(cl);
...
bp::process::handle_type a = c.get_id();
bp::process::handle_type b = self.get_id();
...
c.kill();
self.kill();

Note that the existing "child" cannot magically become "process"
because there are some details not available for a non-child process:
get_stdin et. al.

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

Mmm... aren't Win32's HANDLEs pointers?

There is something that makes me doubt though.  Under Win32, processes
have both an identifier and a handle.  Based on what I outlined above
and the GetCurrentProcessID call you mention, I'm afraid I'm
incorrectly using the HANDLE as the process identifier.

What I mean is: the new "process" class might need to hold the process
identifier (which for a child process is the dwProcessId field) and
the "child" class could additionally keep the child's HANDLE to allow
interaction with it.

Cheers,

PS: On a fourth read of this mail, I'm now fairly sure my code is
wrong.  HANDLEs are used to access the system, but are specific to the
process.  This certainly defeats your desire to print identifiers to
ostreams for debug purposes because a process' HANDLEs could not be
compared with anything.

PSS: If I didn't explain myself correctly enough to make the above
understandable, please let me know ;-)

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