On 6 June 2016 at 12:00, Klemens Morgenstern
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