Re: [boost] Process library with child process events

Subject: Re: [boost] Process library with child process events
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2011-06-02 19:31:09

On Thu, Jun 2, 2011 at 14:57, Jeff Flinn <Jeffrey.Flinn_at_[hidden]> wrote:

> This area needs more work, there is just enough there to support our
> current needs. The boost::process::monitor::join method is used to wait for
> a child process to 'finish' due to whatever cause, which returns the exit
> code on windows and the status on posix.
>
> There is a template method boost::process::monitor::join<class EXCEPTION>
> that throws a default constructed exception of the supplied type when join
> returns a non-zero value.
>
>
Yes, I've seen the join functions but that's clearly not enough. What if the
parent process does have things to do too while the child process works?
It looks like using join would then require a listener thread for each child
process that I want to get notified the end of.
Is it a reasonable way of handling it? It looks like a bit overkill to have
a thread+process pair for each child process...
But maybe there is no other way, I'm not sure because I don't know a lot
about the problem domain.

> Can you provide a more concrete set of requirements?
>

For my personal case ( a game with client/server organisation ) :

One main process that is also a client application.
It launches child processes that are server applications.
The main process simply need to be notified if a child process, a server,
did end. There are, if we don't get into details, two cases:

 1. The process ended correctly : the server ended because of predefined
causes that have been communicated to the parent process.
 2. The process ended incorrectly : an error made the process crash, the
process have been killed by something external, etc.

I need be notified about both cases for each child process to react in a
consistent manner for the user of the client application.
It would also allow me to help catching inter-process problems like a bug
killing the child process without affecting the parent process that does
require the child process to be alive to run correctly.

So the main problem is 2., because it requires the child process to send
informations just before crashing or for the parent process to have a way to
detect such crashes from outside (some kind of ping?).
I don't know how to implement this last suggestion.

>
> The previous iteration(s) of process had an asynch wait facility that may
> be able to be used with the latest design. Boris, do you have any ideas
> here?
>
>
I did give my 2cents about it, It was missing something I don't remember
exactly and/or it was using the thread+process pair solution.

Joël Lamotte