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