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 07:02:33

Am 06.06.2016 um 12:49 schrieb Klaim - Joël Lamotte:
> 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).
>
And that's a bit problematic, since the same code might then behave 
differently on different platforms. But maybe it is possible to create 
some handling
for the current process in the this_process namespace. E.g. a callback 
`this_process::on_exit_request(...)` or a bit 
`this_process::exit_requested()` so you can
also skip the platform-specifics here.

>> 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)
Please, that would help me very much. Also for the child process 
handling, regarding the this_process namespace.
>
>> 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.
Well if there is a portable way, even if it's a hack, I'd look into 
adding it.

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