child::terminate() vs. child::exit_code() value about boost-process HOT 5 CLOSED

The exit_code is considered invalid after calling terminate. That was a design decision, because I thought, if you terminate the thing, you don't really care about the exit-code; I actually can set it on windows. I would however not use an arbitrary value, since I cannot set one on posix.
Now I could add that, i.e. capturing the exit_code, which would make it platform-dependent; i.e. it's not a given my design choice was correct. May I ask do you need that in a real scenario or are you just playing around with the library?

from boost-process.

that's ok, I'm just evaluating the lib. All is fine if it's the design principle.

from boost-process.

Alright then. Well I might get design choices wrong, so if there's a good reason, I'll gladly fix that. Just tell me if you find something.

from boost-process.

I have another suggestion: would if be possible to expand extension's "event" on_... handlers with something like:

on_exit
on_crash
on_terminate
on_<whatever>

It could be done, regarding http://doc.qt.io/qt-5/qprocess.html which is pretty cool API (except mandatory event loop handling)

I'm really picky about APIs, and I can see Qt's QProcess very easy to use. On the other side your api offer almost the same comfort, I'm just missing enhanced status reports.

Just suggesting things from my perspective, no offense here ;)

My long-term usecase is to launch N processes. These processes have to be monitored for their status. Ideally to relaunch on child process crash. So it's up to me now how to get this status.

Please, don't take it as an offense. Boost::process is great lib {ok, I'm not c++ guy, so it forces me to read all src code if I need to do basic things, thats my problem ;)) and it's very easy to use. I just need some "extended" things.

from boost-process.

No problem I'm open to suggestions. One upside to boost.process for you could be that it has an interface for extensions. This also means that you can develop an extension and if you then ask me to add it, it gets much more likel.
I'm not sure where you see the events (i.e. signals) in QProcess but alright, let me explain my rationale: this library doesn't aim to be the perfect process library ,but to provide a thin layer for portability. Thus things that are not solvable in a portable way are not in. And also a custom handler for SIGCHLD wouldn't be the default.
Thus crash, terminate and are all the same namely exit. The problem is: on crash your exit-code is undefined, on terminate, to some degree, also. So it's not really that easy; now posix has some exit-codes defined, but windows hasn't thus (again) I didn't find a portable solution here.

So that's the problem, if I were to accept the overhead, that's not really possible, since I have to assume behaviour of the child process (i.e. the exit codes), which this library cannot. If you know more (since it's your application) you can implement this rather easily yourself.

The way I would handle that is through the asynchronous wait, let's say you want to use boost.signals2 for that, too. (you can put it into a class too, and I hope it works).

using boost::signals2::signal;
namespace bp = boost::process;

signal<void(int)> on_error;
signal<void()> on_failure;
signal<void()> on_success;

boost::asio::io_service ios;
child c("foo", on_exit=[&](int code, const std::system_error &)
           { 
                 if (code == 0)
                     on_success();
                 else if (code == 1); //regular error, THIS IS AN ASSUMPTION about the child process
                    on_failure();
                 else
                    on_error(code);
           });

ios.run();

Btw. if you need some help to get started with process or asio, you can just write me an E-Mail.

from boost-process.