Re: [boost] Process library with child process events

Subject: Re: [boost] Process library with child process events
From: Jeff Flinn (Jeffrey.Flinn_at_[hidden])
Date: 2011-06-02 22:29:38

Klaim - Joël Lamotte wrote:
> 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

Are both the parent/child process application code yours? We accomplish 
something similar by using asio with async socket communication between 
the parent and child processes effectively sending an exit code. If the 
either dies the socket closure manifests as an asio failure. We have a 
single thread with an asio io_service run. But that single thread can 
handle multiple connections to multiple child processes.

>> 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.

IIRC, the async wait of the previous process library would effectively 
work the same way, without needing socket communication, and a single 
thread with the io_service:run call to handle multiple child communication.

As a game you most likely have a gui application. At boostcon Chris 
Kolhoff suggested that you could call, IIRC, io_service::poll from your 
event loop to avoid a second thread.

Jeff