[boost] Re: Child processes

From: Angus Leeming (angus.leeming_at_[hidden])
Date: 2004-06-23 03:47:14

Gregory Colvin wrote:

> On Jun 22, 2004, at 5:33 PM, Stefan Seefeld wrote:
>> Gregory Colvin wrote:
>>
>>>> oh ? Any call to fork()
>>> On systems that have fork().
>>>> should be accompagnied by a call to wait()
>>>> (or one of its cousins such as 'waitpid()').
>>> On systems that have wait().
>>
>> yes, I'm only talking about posix systems.
> 
> But Boost usually cares about other systems as well.

Nice to see I triggered some feedback ;-)

I don't think that cleaning up global resources such as zombies should be
left to the user if the library can clean them up automatically. Posix
platforms emit SIGCHLD signals, so it is natural to use a signal handler
to reap the zombies. Windows does not provide such a mechanism, so we are
forced to use threads.

I'm still at the stage of building thin wrappers around the OS-specific
API. These wrappers have the same public interface, but should be
otherwise free to do "what is natural" on that platform. They can then be
used as blocks to build more complex classes.

As an example of what I mean, consider "class process". This provides a
handle to the child process and, indeed, multiple instances of the class
can point to the same child. Thus, it is natural to implement the class
as:

class process {
        process() : child_(new process_instance) {}
        process(process_data const & data) { spawn(data); }

        void spawn(process_data const & data) {
                child_.reset(new process_instance);
                child_->spawn(data);
        }

        // Other functions invoking child_.
        ...
private:
        boost::shared_ptr<process_instance> child_;
};

The copy semantics of such as class are those of a pointer. Moreover, it
becomes relatively easy to ensure that class process is thread safe
because shared_ptr has the necessary machinery built in.

process_instance has the semantics that one instance of the class
represents a single child. It cannot be copied because the underlying
child cannot be duplicated. Such a design allows system resources to be
freed unconditionally in the destructor. (Eg, file descriptors can be
closed.)

In this design, process_instance is an implementation detail. Posix and
Windows have separate implementations of this class, but these
implementations have the same public interface. Thereafter,
process_instance is free to do what is natural on that platform. On
Posix, that means use fork(), exec() and a signal handler. On Windows,
something else.

Regards,
Angus