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 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://lists.boost.org/mailman/listinfo.cgi/boost