[Mingw-notify] [ mingw-Bugs-1333217 ] ^C handling within msys

[SourceForge.net <no...@so...>]

Bugs item #1333217, was opened at 2005-10-21 02:35
Message generated for change (Comment added) made by dannysmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1333217&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
Group: Known bugs
Status: Open
Resolution: None
Priority: 5
Submitted By: ericgm (ericgm)
Assigned to: Earnie Boyd (earnie)
Summary: ^C handling within msys

Initial Comment:
It is a well-known bug that SIGINT handlers in
Windows/MinGW executables are not called when the user
hits ^C, and the MinGW process exits abruptly.

In addition, it seems that when the executable starts
asynchronously others executables, the others are not
killed, as they seem to not receive SIGINT.

After having analyzed what was going on, it occurs that
the culprit is MSYS (CYGWIN) runtime that do not resend
CTRL_C_EVENT to the actual runtime of the executable.
It works when the runtime is MSYS, but not if it is
MinGW. The attached patch seems to fix the problem.

The basic idea is to send a CTRL_BREAK_EVENT if the
executable is not an MSYS one, but a MinGW one
(remember that sending CTRL_C_EVENT does not call
associated signal handler). The CTRL_BREAK_EVENT is
then handled by MinGW runtime which will emulate the
handling programmed  by the executable. So, there is
one patch for mingw-runtime-3.1 and on set of patches
for msys-1.0.10, and it will required that MinGW
programs to be relinked with the new MinGW runtime.

Thanks,
Eric


----------------------------------------------------------------------

>Comment By: Danny Smith (dannysmith)
Date: 2005-10-21 17:56

Message:
Logged In: YES 
user_id=11494

I do not like the idea of making SIGINT handler the default 
handler for CTRL_BREAK_EVENT's in mingw runtime.  
Overriding a user-defined SIGBREAK handler is just wrong.

Danny.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1333217&group_id=2435