From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2006-08-18 12:15:27
----- Mensaje original -----
De: "Julio M. Merino Vidal" <jmmv84_at_[hidden]>
Fecha: Miércoles, Agosto 16, 2006 5:31 pm
Asunto: [boost] Presentation of Boost.Process (SoC project)
> During the past two-three months Jeff Garland (as mentor) and I have
> been working on the Boost Summer of Code project whose goal was to
> implement a library to spawn and manage child processes. A little
> introduction and a link to the source code can be found here:
> But you'll probably want to go straight to the documentation which
> includes, among many other information, a couple of tutorials and
> multiple examples. I'm keeping an up-to-date snapshot at the
> following URL:
> If it wasn't for the imminent SoC deadline (next Monday), I wouldn't
> present it just yet because there are still a couple of important
> issues that I would like to see resolved as soon as possible:
> First is the lack of a "design decisions" chapter in the
> documentation. This is not an extremely big issue because the Wiki
> page linked above already contains many discussions on the library's
> current design. In other words, that chapter will end up summarizing
> the information in there and adding few new things.
> Second, and very important, is the "need" to integrate the library
> with Boost.Asio to allow asynchronous management of communication
> streams and process termination. Unfortunately it does not support
> such asynchronous events yet, and integrating with Boost.Asio sounds
> like a reasonable approach to cover this area.
> Anyway, I wouldn't like this to discourage you from taking a look at
> the documentation and code. The library is already big enough to let
> you get a general idea on its focus and design. You can start
> criticising now! ;-) Sincerely, any constructive comments will be
> certainly appreciated.
> Thank you.
A cursory look at the docs shows this can be a very valuable
contribution to Boost. Thank you for your effort!
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.
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.
Joaquín M López Muñoz
Telefónica, Investigación y Desarollo
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk