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.