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

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