asdfgroup has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I wonna to receive siginfo struct available in Linux for real-time signals. More specifically, I wonna recieve file descriptor number for SIG_IO events.

After diggin Perl sources I realized I can't recieve this neither in normal Perlish way thru $SIG{signo} handler nor thru POSIX sigaction. This is because Perl declare Perl_sighandler(int) but not like void (*sa_sigaction)(int, siginfo_t *, void *). So small XS was written (skeleton of this XS posted below).

Question : is this safe ? Can my signal handler ruins something ? Can any problems be if my handler fire than Perl for example runs malloc ? And the most important question : is there are any better way to retrieve siginfo in signal handler ?
Question2 : can I safe (relatevely safe :) ) make simple Perl callback in signal handler ? (of course this callback will as small as possible like Perl signal handlers before "Perl safe signals".
//... static int FD_set[MAX_FD], FD_q[MAX_FD]; // Static structures here to not make malloc at all :) static int pos = 1; static int sig; void Handler(int sig, siginfo_t *si, void *whatisthis) { // work like Edge Triggered if (FD_set[si->si_fd]) {; return; } FD_set[si->si_fd] = pos; FD_q[pos] = si->si_fd; pos++; } MODULE = RtSig PACKAGE = RtSig int SetSigaction(arg) int arg CODE: struct sigaction act; sig = arg; act.sa_flags = SA_SIGINFO|SA_RESTART; act.sa_sigaction = Handler; sigfillset(&act.sa_mask); if (sigaction(sig, &act, 0) == 0) { RETVAL = 1; } else { XSRETURN_UNDEF; } OUTPUT: RETVAL void Poll() INIT: int i; sigset_t mask, old_mask; PPCODE: sigemptyset(&mask); sigaddset(&mask, sig); sigprocmask(SIG_BLOCK, &mask, &old_mask); for (i=1; i < pos; i++) { XPUSHs(sv_2mortal(newSVnv(FD_q[i]))); FD_set[FD_q[i]] = 0; FD_q[i] = 0; } pos = 1; sigprocmask(SIG_SETMASK, &old_mask, 0);

Replies are listed 'Best First'.
Re: receive siginfo for real time signals.
by chip (Curate) on Apr 20, 2004 at 01:18 UTC
    Your signal handler setup looks mostly safe, as long as its used properly. You could add some more interlocks to make it safer, like disallowing setting a handler for a new signal if you still have it set for another.

    As for calling into Perl... I can only answer "No!" using a loud voice because the louder voice doesn't have ASCII characters that will represent it. Unsafe signals are unsafe, period, and you must not go there. Really.

        -- Chip Salzenberg, Free-Floating Agent of Chaos

      Hmm... but, if this signal handler setup looks mostly safe, then why perl internal signal handler are so complex, even for unsafe signals?
        I'm afraid that question doesn't make a lot of sense to me. But if you're asking what I think you're asking: It's because signal handling for unsafe signals calls Perl subroutines, and for safe signals, it sets multiple flags checked during OP running.

            -- Chip Salzenberg, Free-Floating Agent of Chaos