Well, it seems you have already implemented most of this stuff. I think it looks great. Did you try to shove any of it into LyX?
Regarding determining exiting on Windows: In addition to the thread, it is also common to just add a timer and poll check once in a while.
That can be built on top of what we've got here: if (some_timeout) child::process_demultiplexor::instance().flush();
That helps avoid threads, which are notoriously difficult to debug.
Granted. I was trying to document the possible strategies.
So, I propose to go for the polling solution, potentially in addition to the signal handler on Unix.
I think that this is the best option.
You need to associate a timer to a window on Windows. You can associate with the top-level LyX window. So, in order to do that, a process manager should probably expose some polling interface, which will poll all the live spawned processes.
Oh, we have timers already. Calling the 'flush()' is trivial.
The LyX core would use the timer to call this polling interface once in a while.
In other words, add a process manager to expose one single point for polling.
Regarding the call-back: How common is it to copy process_data?
I can imagine creating a process_data variable when the converter stuff is parsed, no?
\converter xyz png "my_converter arg1 arg2 $$i $$o"
It might make sense to split the conversion string into an argv array only once. Remember, I'm still in the business of thinking through this stuff.
Can't you just make that class uncopiable, and use the signals?
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.
Regards, Asger
Thanks for taking the time to look at this. Angus
