[bug #51237] Deadlock in Ctrl-C handler on Windows

[Eli Zaretskii]

Follow-up Comment #5, bug #51237 (project make):

> First, we have this same type of issue in UNIX (see for example bug #50557)
so I would prefer to not have a Windows-specific solution.

I'm not sure it's the same issue, although it maybe looks the same.  See
below.

> Second, I don't see why we need a separate thread to handle this. Why can't
we just modify the signal handler to set a flag saying that a fatal signal was
received, then test that flag in appropriate places during the main processing
of make. If the flag is set then we die. Of course, finding the "appropriate
places" is the trick.

Maybe I'm missing something.  When the user presses Ctrl-C, Make gets a
SIGINT.  This causes fatal_error_signal to be called, which then proceeds to
do stuff.  That "stuff" is done entirely in the signal handler, so how can
just setting a flag solve the issue?  Who will do all that "stuff" "during the
main processing"?

> Maybe there's something about Windows that makes this less straightforward
than on POSIX systems? 

Yes, there is: on Windows, the SIGINT handler runs in a separate thread,
created by the system.  That is why the MS-Windows code of the signal handler
begins by suspending the main thread -- because this emulates more closely
what would happen on Posix hosts.

> Finally, this implementation adds a lot more ifdefs to the code.

That should be the least of our problems.  I actually intended to move all the
additional code to Windows-specific files.

But first we need to agree on the solution, so let's forget about ifdef's for
now.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51237>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/