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

Subject: Re: [boost] [boost.process] 0.6 Alpha
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-06-09 04:26:50

On 9/06/2016 19:05, Klemens Morgenstern wrote:
> 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.

No, I don't.  I did find some convoluted code that will do 
SIGINT/SIGBREAK (it does SIGBREAK) at 
https://github.com/walware/statet/blob/master/de.walware.statet.r.console.core/cppSendSignal/sendsignal.cpp 
(link sharing for the lulz), but I don't think this is ASLR safe as it 
assumes that the address of the kernel32 console control handler is the 
same in both processes.  The version that uses AttachConsole is probably 
safer instead.

(Not that SIGINT/SIGBREAK would be a good idea for Boost.Process anyway, 
since many console apps -- eg. cmd itself -- handle that as an 
interactive command and might display an "are you sure" prompt or 
similar.  Which is also just like WM_CLOSE, incidentally.)

Other signals are more problematic, because signals aren't actually a 
thing on Windows, and so the others are just emulated in the CRT.  (And 
processes not raising them themselves probably aren't expecting them 
anyway.)

>> 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.

Now, if you can guarantee that both parent and child use Boost.Process, 
you could probably do it (eg. use a pipe or other IPC mechanism to let 
the parent trigger the child calling raise(SIGTERM) on itself.)  I'm not 
convinced it'd be worth the effort though.