Re^2: When to use sigtrap, when to assign to %SIG?

local $SIG{INT} is a rather strange thing to attempt because that implies that CTRL-C has different meanings at different places in the code. I figure this is a "bad" idea.

It makes sense if you have a block of code that must be completed either in its entirety or not at all, to temporarily disable interrupts. For example, you want to remove a row from one database table and add a corresponding row to another database table. You don't want your code to be interrupted and leave the operation in an incomplete state.

OK, so you'd normally use SQL transactions for that, but what if these two tables are in two different databases, on two different servers, at two different sites?

Easy enough to locally override $SIG{INT}, to catch Ctrl+C and rather than exiting immediately, set an $interrupt_caught variable, and then when it is safe, check $interrupt_caught and exit.

Comment on Re^2: When to use sigtrap, when to assign to %SIG?

Replies are listed 'Best First'.
Re^3: When to use sigtrap, when to assign to %SIG? by Marshall (Canon) on Jan 04, 2012 at 05:45 UTC
Easy enough to locally override $SIG{INT}, to catch Ctrl+C and rather than exiting immediately, set an $interrupt_caught variable, and then when it is safe, check $interrupt_caught and exit. This is not the right way because you are replicating OS functionality. The right way is to set the sigprocmask. You can use this to temporarily disable handling of a particular signal or all of them. If a signal occurs while it is blocked, that status is saved by the OS and when handling is re-enabled, it will be processed. This is called a "pending signal". I give you some C code for a routine that I called right before exiting (while updating a critical structure). The code below didn't save the current mask for later restore, but this is the idea. There are Perl equivalents to this. But since I haven't tested the exact code, and I might make a mistake, I will leave to the reader to research some more. Update: see sigproc mask for the Perl way. The basic idea is not to change "what happens" but rather to delay "what happens". This enables you to right there, in the code that does a critical action, surround it by "block" then "unblock" signal code - no other changes required. `void block_all_signals(void) /* Block 'em Danno! / { sigset_t all; Sigfillset(&all); Sigprocmask(SIG_BLOCK, &all, NULL); return; }` [download] Note: the capital letter forms, like Sigprocmask() instead of sigprocmask() are re-defined versions that do error processing. Handling these extremely rare, but yet important errors is important and it is too easy to forget to check the error return every time so, this technique does that. `void Sigprocmask(int how, const sigset_t mask, sigset_t *old) { if (sigprocmask(how, mask, old) < 0) { perror("sigprocmask"); exit(1); } }` [download] Oh, the "block 'em Danno!" comment is a nod to the Hawaii-five-O TV series. At the end to the show, the main cop always says: "Book 'em Danno" when the bad guys get arrested. I don't consider a bit of small humor in a comment to be an error - so I left it there. In this case it was the "final act" before exit.	[reply] [d/l] [select]
Re^3: When to use sigtrap, when to assign to %SIG? by afoken (Chancellor) on Jan 03, 2012 at 19:19 UTC
For example, you want to remove a row from one database table and add a corresponding row to another database table. [...] OK, so you'd normally use SQL transactions for that, but what if these two tables are in two different databases, on two different servers, at two different sites? <offtopic>Well, Oracle can do that in one transaction, if you use a DB link.</offtopic> Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]