Boost logo

Boost :

Subject: Re: [boost] [boost.process] 0.6 Alpha
From: Rob Stewart (rstewart_at_[hidden])
Date: 2016-06-07 22:06:00

On June 7, 2016 4:59:59 AM EDT, Klemens Morgenstern <klemens.morgenstern_at_[hidden]> wrote:
>Am 07.06.2016 um 10:37 schrieb Rob Stewart:
>> On June 6, 2016 6:49:44 AM EDT, "Klaim - Joël Lamotte"
><mjklaim_at_[hidden]> wrote:
>>> On 6 June 2016 at 12:00, Klemens Morgenstern <klemens.morgenstern_at_[hidden]>
>>> 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
>> 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

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
>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()?


(Sent from my portable computation engine)

Boost list run by bdawes at, gregod at, cpdaniel at, john at