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

From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2006-08-21 18:03:55

Julio M. Merino Vidal <jmmv84 <at> gmail.com> writes:

> 
> On 8/18/06, JOAQUIN LOPEZ MU?Z <joaquin <at> tid.es> 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.
[...]
> 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.

Why not? Aren't these obtainable from ::stdin, ::stdout and
::stderr or similar when the process is the current one?

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

If you hace a Win32 process ID, obtaining a HANDLE can be done
via OpenProcess, so you can have a (id,handle) pair both for
the child and the self cases. The only difference would be in
how the relevant info is gathered (via GetCurrentProcessID
and OpenProcess for self, via CreateProcess for child.)

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

So, if I'm getting you, you'll change your Win32 code so that
handle_type is a DWORD and can then address my requirement
that a guarantee is made about handle_type being always an integral
type, right? Additionally, you can make the guarantee that handle_type
objects are system-wide, which might have some application for
interprocess identification.

Best,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo