Subject: Re: [boost] [boost.process] 0.6 Alpha
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-06-08 22:57:25
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.
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.