On Thu, Jun 2, 2011 at 14:57, Jeff Flinn <Jeffrey.Flinn@gmail.com> 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

On Fri, Jun 3, 2011 at 04:29, Jeff Flinn <Jeffrey.Flinn@gmail.com> wrote:

Are both the parent/child process application code yours?

Yes.

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 project is currently paused but that was what I began to implement, using another library for networking (RakNet). Not sure if it provide an equivalent but if it don't I can still use boost::asio just to do this. So if you tell me it's a safe enough way to handle it using this approach (I don't feel confident in the communication domain so I'm never sure...yet), as I have the source code of both processes, I guess I'll continue on this way.

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.

That's a good idea, I'll see if I can use it that way. Joël Lamotte

On Fri, Jun 3, 2011 at 06:11, Jeremy Maitin-Shepard <jeremy@jeremyms.com>wrote:

This issue is solvable, but it is not easy because it can only be solved by first writing a library to handle certain global state such as SIGCHLD, and this is additionally complicated by the fact that the necessary abstractions are not platform independent. Also, on Windows at least one separate thread might be needed in some cases.

Nonetheless, I think solving it is of critical importance for a Boost Process library.

I believe the 1 thread or regular polling function using asio or similar library can solve my own case, as pointed Jeff, but not the general case where you only have binaries of the other projects and want to be notified. So I agree that it's a very important feature. I'm not experienced enough in the boost community to know if it should be available from the beginning. Joël Lamotte

Giorgio Zoppi wrote:

I think that It is too complicated. Probally I need a more simple layer. Something that i can use:

std:vector<string> arg; p = process('/usr/bin/vi', args=('bob',)); p.start(); p.join();

The current design allows you to do the above, where make_child creates and starts a child process. A monitor allows you to join with a child_process. using namespace boost::process; child c = make_child(paths(“/usr/bin/vi”), args(“bob”)); monitor(c).join();

Something that has an object process_pool.

Can you expand on what you mean by process pool? I've run into a use case where I'd like to launch several processes(one per core) and join all. Is that along the lines of what you were thinking? I do this now in client code but will try to get this formalized and added to the library.

A pipe object between processes, a queue object a signal handler and nothing else.

The library provides a 'directed' pipe, which is currently named boost::process::file_descriptor_ray(yep, in search of a better name). It allows communication between parent and/or child processes. One use is to access a child's std_out via a stream by the parent. For example I needed to grab the output of an exe to parse it's version information: namespace io = boost::iostreams; typedef io::stream<io::file_descriptor_source> source; file_descriptor_ray ray; monitor m(make_child(paths(exe), Args(arg), std_out_to(ray))); ray.m_sink.close(); // currently req's manual closing source redirected(ray.m_source); Tuple version(parse(redirected)); // parse the istream m.join(); Jeff