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]>
>> 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
>>> 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
>>> 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
> 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
> 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
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
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
>> Unsubscribe & other changes:
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk