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/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make