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

Subject: Re: [boost] [boost.process] 0.6 Alpha
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-06-06 06:00:21

> So far I had time only to go quickly through the documentation and a bit in
> the code so here are quick remarks:
>
> 1. It is not clear at all what happen when child object is destroyed.
Oh, ok that's only written in the reference atm. It terminates the child 
process if it wasn't detached or exited before. I added that, will be up 
in the next doc build.

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

> 3. On most platforms there is a way to send a "quit" command to the process
> and a way to kill it by force ("kill -9").
>     Clarifying what is happening in the default cases and having a way to
> terminate one way or the other (or a combination of
>     both, that is requesting termination but force-kill after a time if it
> didn't die)
>     On windows there is an issue with this because the "termination request"
> message can only be received if
>     you didn't build a console application but a windows application (with a
> WinMain) but that only means
>     that the message could be ignored by the process if it's console
> application (there are ways to have both WinMain and
>     a console window, it's just a bit more clumsy to setup).
>
>     In our (Softbank Robotics EU) use of child process tracking we need both
> termination request and forced.
>
>     One could argue that the termination request do not need to be
> implemented by this library but it would be very useful
>     to have a cross platform function doing this for simple cases.
 From how I understand it, you send the terminate request do the HWND 
handle, not the proc handle. That technically means, that you cannot 
tell the process to exit, but a part of it. Hence I don't consider this 
the same as signaling the process to exit, which means it's not 
portable, thus I do argue it shouldn't be part of the library. If I have 
a child::request_exit function, it must work on all processes, not just 
some of the windows-procs. If there was a portable way to do it, it 
would be part of this library.
I think it's easy enough, you can get the pid (or even gid, if you use a 
group) and implement that in two lines. On windows you can get the HWND 
as an std::intptr_t through a pipe, though that's a bit more code.

Thanks,

Klemens