Re: [boost] [boost.process] 0.6 Alpha

Am 07.06.2016 um 10:37 schrieb Rob Stewart:

On June 6, 2016 6:49:44 AM EDT, "Klaim - Joël Lamotte" wrote:

...

On 6 June 2016 at 12:00, Klemens Morgenstern wrote:

...

2. The way child process termination is implemented for each platform

...

should be documented.

Makes sense. It's TerminateProcess on windows and "kill -9" on posix. (also added) That's too harsh as a default. Default signal handling in Posix systems means that sending SIGTERM first would signal a graceful exit. That doesn't mean the process will exit successfully or that it won't ignore the signal, so after waiting for a limited time (user specified with a default), you would send SIGKILL.

(You could actually send SIGTERM, SIGINT, and SIGQUIT, one after the other to increase the chance that the process recognizes the need to exit.)

On Windows, you can send WM_CLOSE. The process may respond within the allotted time and it may not (it certainly won't if it's an ordinary console app). TerminateProcess() is the final step if the process handle isn't signaled within the timeout period.

Thus, terminating a process behaves similarly on both platforms: try a nice signal, wait, then terminate it forcefully if need be. I actually thought the same thing, but it is an issue of security. Consider this:

ipstream is; child c("prog", std_in < is); is << generate_input() << endl; Not if generate_input throws, I need to terminate the child, elsewise I get a deadlock (since "prog" waits for input). If you do not want this, you can detach it or join it. In that it is similar to std::thread, though it doesn't terminate the current process. Now using a timeout would be possible, but I really don't like to set an arbitrary value here. Regarding the WM_CLOSE version: I currently don't think that is a really portable solution, since you signal the HWND not the Process, which means that console programs will cause problems here. Joël Lamotte recommended a similar solution and will send me some examples, so a child::request_exit() function might be added. Now if that happens, I still will not change the behaviour in child, but you might be able to do this then: soft_exit se (child("thingy"), milliseconds(100)); It really depends on how this can be achieved on windows; I didn't look into that, because it's not part of the Process handling in the WinAPI, but maybe there's a workaround.

___ Rob

(Sent from my portable computation engine)

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost