|
|
Subscribe / Log in / New account

why blocking sigint ?

why blocking sigint ?

Posted Sep 30, 2022 14:46 UTC (Fri) by farnz (subscriber, #17727)
In reply to: why blocking sigint ? by ballombe
Parent article: How to fix an ancient GDB problem

I've worked on a codebase that blocked SIGINT whenever it entered a critical section, and unblocked it afterwards. This was a poor way to avoid being killed by the end user hitting Ctrl-C to escape the program at an inopportune moment (not least because it didn't account for Ctrl-\ or Ctrl-Z), but it worked well enough for the use case in question, since users just spammed Ctrl-C until it died.

A proper fix was to replace this with a signal handler, and teach the critical sections to check to see if there had been a SIGINT while they were in progress (exiting immediately once you were out of the critical section). But that took maintenance work being done for other reasons - it wasn't something that was going to get fixed until I had to do some work to port to a new OS.


to post comments

why blocking sigint ?

Posted Sep 30, 2022 15:15 UTC (Fri) by ballombe (subscriber, #9523) [Link] (2 responses)

> A proper fix was to replace this with a signal handler, and teach the critical sections to check to see if there had been a SIGINT while they were in progress (exiting immediately once you were out of the ).

Yes, that is how my project does it too. Just adds a signal handler that set some flag, and check the flag when leaving the critical section. Much nicer than blocking SIGINT.

why blocking sigint ?

Posted Sep 30, 2022 15:17 UTC (Fri) by farnz (subscriber, #17727) [Link]

Yes, but this also requires competent programmers, as opposed to people who flail around until they find something that fixes the reported bug (users killing the program with Ctrl-C when it can't safely be interrupted without triggering a full DB recheck).

why blocking sigint ?

Posted Oct 3, 2022 18:06 UTC (Mon) by iabervon (subscriber, #722) [Link]

If you're really just going to set a flag, the fact that a blocked signal is pending is effectively a flag that the kernel handles for you without any fuss and without interrupting syscalls. If you install a signal handler, you get to find out how well your program handles getting a ton of short writes or EINTR in a critical section when the user hammers ctrl-c. Your program should handle it well, but that path is probably not being exercised at all under normal operation.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds