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