EDIT:
I wrote this kind of hurriedly and right after I was first introduced to signal.h so my initial question was kind of all over the place & boggled down by a lot of messier parts, which likely made it more tiresome/difficult to answer. I also seem to have misunderstood the "masking" part of signals – I seem to have thought that the masking meant that the signal would just be discarded, but in reality, I think what happens is that the handler isn't getting triggered, but the signal is transferred and is "on hold" (with repeated signals being coalseced) until returning from the handler.
Rephrasing here to highlight those parts of my original question that still confuse me (and the original remains below so as not to leave existing comments etc without clear context):
As far as I know, signal handlers are triggered upon kernel mode to user mode transitions. Citation:
(In case the image ever breaks, for whatever reason – it's a quote from man 7 signal: "Whenever there is a transition from kernel-mode to user-mode execution [...] the kernel checks whether there is a pending unblocked signal for which the process has established a signal handler.")
I scribbled the following code:
const char* ON_SIGTSTP_ENTRY = "Got SIGTSTP.\n";
const char* ON_SIGTSTP_EXIT = "Exiting SIGTSTP handler.\n";
const char* ON_SIGINT_ENTRY = "Got SIGINT.\n";
const char* ON_SIGINT_EXIT = "Exiting SIGINT handler.\n";
void ctrlZHandler(int sig_num) {
write(1, ON_SIGTSTP_ENTRY, strlen(ON_SIGTSTP_ENTRY));
kill(getpid(), SIGINT);
write(1, ON_SIGTSTP_EXIT, strlen(ON_SIGTSTP_EXIT));
}
void ctrlCHandler(int sig_num) {
write(1, ON_SIGINT_ENTRY, strlen(ON_SIGINT_ENTRY));
kill(getpid(), SIGTSTP);
write(1, ON_SIGINT_EXIT, strlen(ON_SIGINT_EXIT));
}
int main() {
if(signal(SIGTSTP, ctrlZHandler) == SIG_ERR) {
cout << "Failed to set SIGTSTP handler." << endl;
}
if(signal(SIGINT, ctrlCHandler) == SIG_ERR) {
cout << "Failed to set SIGINT handler." << endl;
}
kill(getpid(), SIGTSTP);
cout << "Returning from main." << endl;
return 0;
}
The output infinitely followed the pattern of:
Got SIGTSTP.
Got SIGINT.
Exiting SIGINT handler.
Exiting SIGTSTP handler.
Got SIGTSTP.
Got SIGINT.
Exiting SIGINT handler.
Exiting SIGTSTP handler.
This is a little strange to me, since this implies that what happens is that we enter the SIGTSTP handler, and then within it the SIGINT handler, then we exit both – and then instantly get both triggered again, without making any progress with the rest of main().
I'd have guessed that what would happen is more similar to that we get one of those sigtstp-into-sigint cycles, then reach the printing in main, which in turns triggers a kernel mode-user mode transition, which triggers another signal-cycle, after this point we return from main (perhaps with another few cycles as more system calls start firing after main's end).
However, it seems like the printing in main is never actually reached: kind of like the next signal handler is fired right after we return from the signal handler, but as far as I understand it, returning from a function should not generally trigger a user mode to kernel mode transition (though maybe signal handlers are different?).
Would appreciate an explanation regarding this phenomenon and my misunderstandings about it.
ORIGINAL:
To my understanding, until we return from a certain signal handler, signals of the same type that invoked it are masked; we won't get that same signal handler triggered another time.
Based on this, I attempted something like the following:
I registered handlers to two different signals (SIGFPE and SIGINT, if that matters), and in each of those two, sent the other signal to the process. That is to say, something like:
void fpe_handler (int signum) {
kill(getpid(), SIGINT);
printf("fpe\n");
}
void int_handler (int signum) {
kill(getpid(), SIGFPE);
printf("int\n");
}
After this point, I got the signal triggered by using sleep(3);, so that we have some system call being triggered in the background to initiate a kernel-mode-to-user-mode switch and trigger available handlers, and then I opened another bash instance and sent a SIGFPE to my process.
What happened at this point is something I can't quite explain to myself: my process had entered an infinite loop.
The reason this is confusing to me is the "understanding" I'd opened this question with. As I was trying to predict what would happen before running my code, I thought: I trigger SIGFPE's handler, fpe_handler; at this point, kill is called to trigger SIGINT's handler, int_handler; this once again sends a SIGFPE, but fpe_handler's run hadn't yet concluded, so this will not, at this point, have an effect – at which point int_handler will return, passing the execution over to fpe_handler's printf, and then back to main. Maybe there'd have been another syscall or two due to libc shenanigans, but even then, just a finite amount of prints.
I then thought: maybe what would actually happen is that instead of being returned to fpe_handler's printf, I'll be returned to fpe_handler's kill – thus triggering an infinite loop of int_handlers, because fpe_handler never concludes and so can never be called again, but nothing stops us from entering-and-quitting int_handler again and again.
However, neither happened: the output was not a repeating int message, but repeating alternatinv fpe and int messages, meaning fpe_handler does indeed get triggered again and again due to int_handler's kill calls.
Why does this happen? What am I misunderstanding?
