Boost logo

Boost :

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:
> _______________________________________________
> Unsubscribe & other changes:

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