Boost logo

Boost :

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2005-02-20 13:39:13

Julio M. Merino Vidal wrote:

> Among the classes I wrote, there are some that provide an abstraction
> layer to launch other (child) processes. Once the process is launched,
> the code can access its standard input/output/error streams by using the
> standard iostreams framework.

There is clearly a need for this sort of library.

I'd like to see something like this follow the style of Boost.Threads
where that makes sense. Besides support for starting processes,
accessing their IO streams, and waiting for them to complete, I'd like
to see support for interprocess synchronization.

Also, it is extremely important that the interface does not hide
features of the underlying OS interface, as is vogue for many
irresponsible "frameworks." For example, if the OS allows processes to
be suspended, but the basic interface doesn't because not all popular
OS's possess this ability, the library MUST make provisions for a user
to be able to access this ability through some sort of extension. This
may mean an implementation that uses runtime polymorphism rather than
concrete types.

One very important implementation issue for this library is that it is
aware of blocking operations. It's often forgotten that
process-spawning code is blocking code due to its interaction with the
filesystem. A black-box interface that might arbitrary block for a long
time, without giving the user proper indication that this may happen, is


Boost list run by bdawes at, gregod at, cpdaniel at, john at