To: cc: mjd Bcc: mjd-ok Subject: Alternative architecture for signal handling Organization: Plover Systems -------- The following would allow Perl programs to handle signals safely, without incurring any significant overhead. Suppose there was another special case for values you could assign to %SIG. In addition to 'IGNORE' and 'DEFAULT', you could assign 'FLAG'. This would mean that Perl would register the following subroutine as a signal handler for the specified signal: volatile sig_atomic_t signal_flag[MAX_SIGNAL]; void sighandler(int signal_number) { signal_flag[signal_number] = 1; } Setting a single variable of type volatile sig_atomic_t is guaranteed safe by both C standards. An XS module would provide access from Perl to the signal_flag array. The interface to Perl might look like this: use SignalFlags, \@signalflags; This makes @signalflags into a magical variable which reflects the value of the C array signal_flag. Having done this, a programmer would then register the signals in which they were interested: $SIG{USR1} = 'FLAG'; Now whenever the program receives SIGUSR1, it will catch the signal and set the flag. It will not dump core, because it has not called any functions, including malloc(), inside the signal handler. Back at the Perl level, the programmer can periodically check to see if $signalflags[USR1] is set. If it is, they can do what is needful and then clear the flag. This does not have the usual behavior of calling a subroutine asynchronously when a signal is delivered. But it does provide a way to detect when a signal is delivered, and it is absolutely safe. It would not impose any speed penalties; the only cost is a single extra string compare at the time the %SIG array is assigned to. Is this worth doing? Is there something I didn't remember?