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