Am 09.06.2016 um 04:57 schrieb Gavin Lambert:
On 8/06/2016 21:19, Klemens Morgenstern wrote:
It doesn't work really, especially since SetConsoleCtrlHandler does only allow two values (Ctrl+C & Ctrl+Break), which are both not clearly termination requests, but more of a terminate command I think. Also to do that, I would need to put all those child processes on a new process group, which would mean, that Ctrl+C will NOT be transmitted to them. That's also a dealbreaker.
Ctrl+C is equivalent to SIGINT and Ctrl+Break is equivalent to SIGBREAK. So if you want to send one of those two signals then GenerateConsoleCtrlEvent is probably the right way to go. (You might need to use CreateRemoteThread to make the child raise it itself rather than doing it in the parent process though, which requires different versions for 32-bit vs. 64-bit processes.)
If you want to raise SIGTERM, this is possible but you'd have to use CreateRemoteThread to call raise(SIGTERM) directly in the child process. Where this gets a little tricky is that you'd need to call the right version of "raise", which differs depending on the CRT the child process uses (static or dynamic, different compiler versions, etc) -- and the required code differs between 32-bit and 64-bit processes too. But I would need to know which binary is executed, then use LoadLibrary to get it, and then look for the entry point, so I can pass it to CreateRemoveThread, right? Do you have an example on how to do this? I would need to be able to this for ANY process having the raise function.
And of course both of the above are dependent on the console app developer actually intercepting and processing them as a graceful shutdown -- otherwise it's little different from a TerminateProcess.
Services are really the only kind of executable that have a defined way to externally start/stop them programmatically. Other process types have interactions that *can* do so but they're intended for user action rather than programmatic action. (Even WM_CLOSE for GUI apps isn't always the right answer, depending on app design.)
Typically graceful programmatic shutdown is only possible when both parent and child are made by the same developers so that they can do something custom to request it.
Sad, but true. That's why it probably won't be part of boost.process.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost