Programming

Hmmm... there seems to be two very different questions here. For your first question about how to write a signal handler that will interrupt itself, the code that I posted really will work provided that you let the prinf finish prior to sending another signal. If this isn't working for you then you not timing the signals correctly. So let's just automate the procedure with a child process that will send the signals with correct timing:

Code:

#include <stdio.h>
#include <signal.h>
void callme ( int sign )
{
        printf ( "Called \n" ) ;
        sleep ( 5 ) ;
        printf("Finished sleeping \n");
}
main ( )
{
        sigset_t mask ;
        struct sigaction action ;
        if(fork()) {
                sigemptyset( &mask ) ;
                setvbuf(stdout, NULL, _IONBF, 0);
                action.sa_mask = mask ;
                action.sa_flags = SA_NODEFER ;
                action.sa_handler = callme ;
                sigaction ( SIGUSR1 , &action , NULL ) ;
                while ( 1 ) ;
        } else {
                sleep(1);
                kill(getppid(), SIGUSR1);
                sleep(1);
                kill(getppid(), SIGUSR1);
                sleep(1);
                kill(getppid(), SIGUSR1);
                sleep(30);
                kill(getppid(), SIGTERM);
                exit(0);
        }
 }

I just can't believe that this will fail on any unix system. You should see:
Called
Called
Called
Finished sleeping
Finished sleeping
Finished sleeping
Terminated

The handler is not simply being called three times. It is really interrupting itself. I don't see how you can prove that it is interrupting itself without a second printf or allowing the first printf to output a few charaters then get interrupted by a second call to printf. printf is not prepared to be interupted by a second call to itself. At best you might see:
CaCaCalled
but I don't see any chance of that unless you completely unbuffer and even then it's dicey. It really depends on how it was written. The best move is to allow printf to finish before sending a second signal.

At some point a second question has been introduced here about sending a lot of signals to a process in a very short time. If a signal is generated more than once before it is delivered to a process, that is too bad. Only one signal will be delivered. Is that why you don't want to defer a signal? Yes, that will help reduce the chance of it happening but there is no complete solution to this problem. Suppose that your process is sitting on a run queue waiting for a cpu. If another process that does have a cpu sends it 5 copies of the same signal, what can the kernel do? When the process runs, it will get one signal.

Since you mention SIGCHLD specificly, this happens to init 100's of times each day. Several children exit, but init only gets one signal. init simply wait()'s in a loop until a wait() fails with ECHILD. If you treat SIGCHLD to mean that zero or more zombies need to reaped, the problem sort of goes away.

If that's what you have to say then any form of Signal I/O is at stake.
External events which generates signals are not to our coding standard. They occur asynchronously at any time. Take an example in a signal driven I/O for Sockets:
When data arrives , the signal is generated. While the signal handler is executing ( reading data ) , two more data packets arrives at same time , causing signal to be generated two more times but as per our discussion the signal handler will be called only once. Hence the third data packet will only be read only when fourth data packet arrives at the port.

I feel that because signals are not queued ( to a process they are bit flags ) that the problem of multiple instances of same signal exists.

In that case the signal handler should be prepared to read 0 or more packets for each receipt of a SIGIO.

Looking at a few manpages, I see that doing this portably is easier said than done. It looks like you can set the O_NONBLOCK option and then loop doing recv() until you get -1 with errno set to either EAGAIN or EWOULDBLOCK.

But in general, this is the trick. Whatever the signal means, you need to handle it zero or more times. With any signal delivered to a process by the kernel there should be some way to loop attempting what is required and detecting when you've done that thing enough.

If another process is sending you signals with the expectation that your process can reliably count them, then someone made a design error. The processes would need to switch to another form of IPC.

If yours interested to know: it works fine on GNU gcc 3.2 with Linux kernel 2.4.20.

output:

Called
Called
Called
Finished sleeping
Finished sleeping
Finished sleeping
Terminated

The sigaction structure includes the following members:

void (*sa_handler)();
void (*sa_sigaction)(int, siginfo_t *, void *);
sigset_t sa_mask;
int sa_flags;

What is the purpose of the third parameter ( void * ) in the member variable void (*sa_sigaction)(int, siginfo_t *, void * ) of sigaction structure.

Thanks in advance

I have never actually used that so my knowledge is limited, but I'll tell you what I know.

When a signal handler is called the kernel may change a few things first. It may block some extra signals. It may install a special stack is sigaltstack() was called. So when the signal handler executes a return statement, it cannot actually return immediately to the interrupted program. Instead, the return statement will jump to a little piece of code that will put things back the way they were prior to the signal handler being called. Then that little piece of code will jump back to where the process was when it was interrupted. Some people call that little piece of code a "trampoline".

The trampoline knows what to do because there is a structure called a "context" which indicates the way things were. The third parameter is a pointer to the saved context structure. The getcontext() and setcontext() system calls also work with pointers to contexts. Those man pages will lead you to more info on the context structure.

I never use setjmp() and longjmp(). I think that sigsetjmp() and siglongjump() will take care of this stuff so that if you use sigsetjmp in a program, you can safely siglongjmp() out of a signal handler. If that thinking is correct, and I'm not sure that it is, then I am having a hard time imagining a way to actually need to modify contexts. The only one I can think of is to setjump in one signal handler and then to longjmp back into that signal handler from a second signal handler. But there is no way that I'm going to try that.