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

6 Jun 2016


      Am 06.06.2016 um 12:49 schrieb Klaim - Joël Lamotte:
...
On 6 June 2016 at 12:00, Klemens Morgenstern 
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