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