Angus Leeming wrote:
That can be built on top of what we've got here: if (some_timeout) child::process_demultiplexor::instance().flush();
process_demultiplexor and flush are strange names, which I do not understand. Can you come up with something better than that?
demultiplexor: I was using the language of Hugo Duncan (author of the giallo.sf.net OS-independent sockets/named pipes project) and of Aaron LaFramboise. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Multiplexing/AaronsMultiplexingIdeas
Equivalent URL: http://tinyurl.com/7ydyf
Lots of different child processes are launched and all are monitored in only one place. That's the "many inputs one output" definition of a demultiplexor.
flush: there's a separation here between monitoring the child processes to see when they exit (reaping the zombies in unix parlance) and actually calling the registered slots.
Sure these can be done at the same time. That's an explicit polling strategy. However, a unix signal handler or a "one thread watching each child process" would update only an array of "completed processes". In such an approach, flush() would simply loop over the slots associated with these completed processes and "flush" them from its store.
Make sense now?
Sure. But maybe the slot that's called when the child exits would like to see the command that (say) failed. Doesn't need the signal stuff but the argv array and any redirection stuff might be useful in a debug message.
Split the process_data into two classes. One with the copiable stuff, and another with the call-back stuff.
Or, in the language of Alexandrescu, use Policies to parameterise the process_data class.
I assume that the process_data, in addition to the executable and command line parameters and pipe redirections, also can contain stuff like the used environment variables, the directory which the process should start in, platform specific stuff like whether the process starts minimized, maximised, etc., the process priority and so on.
In general, yes. For example, you might imaginge a "command line parser" that creates a process_data variable out of this little lot:
"foo bar > outfile 2>&1 < input"
(Have I mentioned that I've written such a beast ;-)
With such stuff in there, you almost have a boost::process candidate.
I'll have a candidate for "initial discussion", yes. I probably don't have enough breath in my body to see it through.
In other words, to have that, I believe you have to make a system which can almost replace the platform specific APIs with little overhead, so that there is no reason for ever going to the native API.
I think that the trick to writing such a flexible beast is to get the basic framework right. The stuff I posted feels right to me. All the flexibility will be needed only in process_data and in the spawn_process function. Once the thing is spawned, then interaction with it is relatively constrained.
Regards, Asger
I read elsewhere that paternity leave is now at an end. It's been fun having you around so much.
Angus
