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

Subject: Re: [boost] [boost.process] 0.6 Alpha
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2016-06-06 06:49:44

On 6 June 2016 at 12:00, Klemens Morgenstern <klemens.morgenstern_at_[hidden]>
wrote:

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

For the HWND handle I believe it is directly related to the process if it
is a native windows application (a console application is similar but with
additional
code to instantiate the console window).
All OS we use have a platform-specific way to request exit to a process
(and signals are manageable on all these platforms).
What I am suggesting is to provide a cross-platform function doing the
platform-specific request, which would give a chance to the child process
to
kill itself. One can implement this with their own protocol too, but as
platform-specific protocols are already there, having a ready way to do it
would help.

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

Sending the request does work on all processes. Reading it is skipped by
some special implementation of windows processes, like console processes.
Even with a native windows process, or a linux process, you still have to
do some platform-specific message processing in the child process code
to manage this request, which is fine to me (and could also be generalized).

> If there was a portable way to do it, it would be part of this library.
>

I don't see any way in which it is not possible to make it portable. I can
provide example if you want? It's clumsy but it shows how we do it. (see
below)

> 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.
>
>
Exactly. Which is why I think such function would be a good candidate for
this library, although it's not a show stopper to me.

> Thanks,
>
>
> Klemens
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>