On 8/18/06, Sebastian Redl <sebastian.redl@getdesigned.at> 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@gmail.com> The Julipedia - http://julipedia.blogspot.com/