kill() / signal() doesn't really work.
hyc opened this issue Β· comments
Currently MSYS isn't able to send signals to ordinary Win32 programs. A long time ago I wrote a patch for MSYS1 to accomplish this. https://sourceforge.net/p/mingw/mailman/message/10716023/
It would need refreshing to handle 64bit and 32bit binaries but otherwise should still work. Is there any interest in supporting this?
Something like this was implemented in #31 if I'm not mistaken.
That patch only fixes Ctrl-C handling in a console window. The patch I linked to above handles SIGINT/SIGQUIT/SIGKILL/SIGTERM and works even if the target process isn't attached to a terminal.
That patch only fixes Ctrl-C handling in a console window. The patch I linked to above handles SIGINT/SIGQUIT/SIGKILL/SIGTERM and works even if the target process isn't attached to a terminal.
The patch I linked mentioned them all, and it was written before we used conpty, so also without a attached console.
I don't know much about this, but I think we need an example that you want to work, but currently doesn't, to see if anything is missing.
I see, didn't read the entire patch thoroughly before. For the moment the only problem I seem to be having is that SIGTERM just calls ExitProcess() so it bypasses any signal handlers.
Just wondering, is there any Windows software using SIGTERM handlers? And if yes, why?
@lazka, maybe that MSDN page could shed some light:
The
SIGILL
andSIGTERM
signals aren't generated under Windows. They're included for ANSI compatibility. Therefore, you can set signal handlers for these signals by usingsignal
, and you can also explicitly generate these signals by calling raise.
OTOH there might be some F/LOSS that got ported to Windows + CRT and are historically still trying to handle these two.
OTOH there might be some F/LOSS that got ported to Windows + CRT and are historically still trying to handle these two.
Exactly. SIGTERM
is also the default generated by the kill
command.
OTOH there might be some F/LOSS that got ported to Windows + CRT and are historically still trying to handle these two.
This seems like a bug to me, or potentially problematic if code is executed then which is not meant for that platform.
@lazka, that was a hypothetical case, and I didn't generated it whole.
The part I omitted might be a guarding thread/process that logs the stack traces of the remaining threads/child processes, and then sends SIGTERM (in platform-dependent ways) to them.
Of course, having a working example would make things clearer :)
That patch only fixes Ctrl-C handling in a console window.
That is distinctly untrue. That patch is not even necessary in a Console window. That patch was specifically to get SIGINT
handlers working in MinTTY, without any Console, not even a pseudo console.
TBH I consider #31 to have addressed this ticket before it was opened π
TBH I consider #31 to have addressed this ticket before it was opened π
Mostly. There are still a few signals that the CRT supports that aren't addressed in #31, so the remaining question is if anyone else cares enough about those missing signals. SIGTERM is most significant to me but others might be useful once in a while.
It has been pointed out that the "missing signals" are not produced by Windows. I see very, very little point, then, to produce them in the MSYS2 runtime.
The only reason to handle SIGTERM
in a special way is to give the atexit()
handlers a chance to run, which the existing code (as of #31) does.