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?
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.
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.
With such stuff in there, you almost have a boost::process candidate. 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.
Regards, Asger
