Subject: Re: [boost] [boost.process] 0.6 Alpha
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-06-09 03:05:21
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://listarchives.boost.org/mailman/listinfo.cgi/boost