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

On June 7, 2016 4:59:59 AM EDT, Klemens Morgenstern wrote:

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:

...

It's TerminateProcess on windows and "kill -9" on posix.

...

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.

I see your point. You could provide a default timeout for that case and include a function permitting the user to override that default.

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.

I mentioned that. Sending signals on posix systems may not terminate a process either. That's why you fall back on SIGKILL. On Windows, you try the WM_CLOSE approach and fall back on TerminateProcess().

Joël Lamotte recommended a similar solution and will send me some examples, so a child::request_exit() function might be added.

The remote thread technique sounds interesting.

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));

Why not c.terminate(milliseconds(100)) and c.kill()? ___ Rob (Sent from my portable computation engine)