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

Subject: Re: [boost] [boost.process] 0.6 Alpha
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-06-09 12:39:12

Am 09.06.2016 um 10:26 schrieb Gavin Lambert:
> 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.

Well, it keeps the style of the WinAPI :)

"The Windows API has done more to retard skill development than anything 
since COBOL maintenance." (Larry O'Brien)

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

I came accross boost.application, that would probably be a better 
candidate to emulate signals if we need a custom receiver on the 
child-side.
>
>>> 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.
>
Neighter am I, I'd do it, if it was easy.

However: I've decided to definitely not add this until boost.process is 
reviewed - which will still take a lot of work.
We have not discussed four approaches to this problem and no one cuts it 
in my opinion. If one shall be added, it must be tested before. So I'd 
accept a pull request if it is either marked experimental or a 
platform-extension. There will however not be a standard way to do this 
until the first release of the library. I don't think having no SIGTERM 
will be a deal-breaker and if we have an accepted boost.process it will 
be much easier to experiment with that stuff.

I will however summarize the ideas and reopen the discussion when I 
think boost.process is ready for experimental features.

>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>