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
>> 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.
Ok, here goes.
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
* 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
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
Does this make sense now?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk