[boost] Re: Proposal: Library to manage processes

From: Angus Leeming (angus.leeming_at_[hidden])
Date: 2005-02-22 04:58:17

Jonathan Turkanis wrote:

> Angus Leeming wrote:
> 
>> I've recently picked up the baton of what the library itself would
>> need and started trying to discuss the possible alternatives. See
>> here:
>>
>> http://www.devel.lyx.org/~leeming/process/
>>
>> It seems to me that the hardest part of writing such a library isn't
>> the code to spawn the process in the first place at all. Rather it's the
>> code to monitor the status of a running process and to notify the rest
>> of the code when it has exited. I suspect that an Alexandrescu-style
>> policy-based design will be needed, but with a twist. Once a
>> singleton process_monitor variable is created, invocation of any
>> other policy should become an error.
> 
> Could you elaborate a bit on how the policy-based design would look? In
> particular, are you saying it would resemble the Loki singleton, or just
> that it would involve policies of some sort? Also, I'm not sure what you
> mean by invoking the policies.

Hi, Jonathan.

Ok, here goes.

Aaron LaFramboise 
(http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?action=browse&diff=3&id=Multiplexing/AaronsMultiplexingIdeas
Equivalent URL: http://tinyurl.com/5q7ch)
and Hugo Duncan (http://giallo.sf.net) both talk about a "demultiplexor" 
to monitor the state of all processes that have been spawned by the 
parent. Such a demultiplexor (perhaps "monitor" is a clearer name?) can 
use one of several different mechanisms to monitor these processes. For 
example:

* It could poll the state of all registered processes explicitly when 
requested to do so.
* It could install a signal handler for SIGCHLD signals and update a local 
store of completed children.
* It could spawn a thread to watch the state of a single child, this 
thread returning when the child exists.

No one of these policies is perfect, so it makes sense to provide all 
three as policies.

Similarly, how should such a demultiplexor inform interested parties that 
the child has completed? The obvious way is to store a Boost.Signal and 
emit it on process exit. But Boost.Signal is noncopyable, so it must be 
hidden inside some wrapper class with pointer-like copy semantics. More 
importantly, it cannot be used to communicate across threads. So, 
Boost.Signals won't cut it in a multithread world but is perfect in the 
singlethreaded world.

Conclusion: the process demultiplexor should be a template with policies 
for the polling and for the callbacks. However, the demultiplexor should 
also be a singleton. Probably. (I imagine a signleton with a Zombie 
lifetime policy; it can be resurrected once it has died but will not emit 
signals.) Moreover, once you've registered one 'flavour' of demultiplexor, 
all other flavours should be forbidden.

I think this can be achieved with a child_config.h that is #included by 
all other child source files and which the user must use to specify the 
demultiplexor.

Does this make sense now?

Angus