Catching signal inside its own handler

Question

#include<stdio.h>
#include<signal.h>

void handler(int signo)
{
    printf("Into handler\n");
    while(1);
}
int main()
{
    struct sigaction act;
    act.sa_handler = handler;
    act.sa_flags = 0;
    sigemptyset(& act.sa_mask);
    sigaction(SIGINT, &act, NULL);
    while(1);
    return 0;
}

After catching the KeyboardInterrupt once, when I press "Ctrl+C" again, SIGINT is not handled... I intend that "Into handler" should be printed each time I press "Ctrl+C".

I want to catch SIGINT inside the "SIGINT handler()" itself..

Oyler

Answer 1

You need to set SA_NODEFER on sa_mask to catch the same signal as the one you're currently handling:

SA_NODEFER: Do not prevent the signal from being received from within its own signal handler. SA_NOMASK is an obsolete, non-standard synonym for this flag.

Repute

Beware: this doesn't guarantee that you won't lose signals! If your process gets multiple, non-realtime signals of the same type while it isn't on time slot or in uninterruptable kernel call, then the second (and further) signals will be lost. – Implacable

Answer 2

What you are doing seems like a very bad idea, though, and it might be better to simply set a flag from the handler and return from it, and then do the printing from main.

You need to set SA_NODEFER or otherwise re-enable the signal within the signal handler itself because otherwise the signal gets blocked or switched back to its default behavior right before the call to the handler.

Calling printf from a signal handler is undefined behavior. It may crash your program. The list of functions that you actually can safely call from a signal handler is very limited. I need a list of Async-Signal-Safe Functions from glibc

Karlis

+1 on the "seems like a very bad idea". In general, keeping your signal handlers as short and simple as possible is the way to go. – Jump

thats why I wrote "sigemptyset(& act.sa_mask);" so that no signal is masked.. Where am I wrong? – Oyler

Actually, I want to learn "how to catch a particular signal inside its own signal handler?". thats why I asked the question – Oyler

The signal is blocked (or handler changed to SIG_DFL) right before the signal handler is called. What you set before that (in main) has no effect. – Karlis

As it says in the man page, it depends on the implementation. On Linux it simply blocks the signal before calling the handler and unblocks after the handler returns. – Karlis

Answer 3

Using the printf function within a signal handler is not exactly a good idea to use as it can cause behavior that is undefined! The code sample is missing a vital bit for the signal handler to work....Have a look at my blog about this here on 'Q6. How to trap a Segmentation fault?'

Also, you need to replace the while loop with something more robust as a way to quit the program while testing the signal handler...like...how do you quit it?

Normy

I have just started reading about signals... So, whats the proper way? – Oyler

Look at the code, you will 'sigemptyset', then the flags is set, and 'sigaction(SIGINT, &sigact, (struct sigaction *)NULL);' is called after it...which traps the SIGINT..you are setting the flags before calling 'sigemptyset'..btw this was used in production environment and works happily under AIX... – Normy

Answer 4

You can use something like this instead of printf:

const char *str = "Into handler\n";
write(1, str, strlen(str));

The function write(..) is safe to be called from signal hanlder. Don't forget to include unistd.h header to use it.

Thurston

You are probably more safe referring to stdout rather than 1 as a variety of means could cause this number to change. – Polydactyl

Answer 5

The "while(1)" in handler is preventing the first service call from ever returning. Remove that and subsequent interrupts should cause handler to be called again.

An interrupt service routine should not prevent the calling thread from returning.

Abell

Then rewrite your Unix kernel. – Anisotropic