Synchronous signal handling [LWN.net]

While fixing various problems in the signal handling code of recent kernels, Linus evidently decided to take a stab at the issue of signal handling races. The result was this patch implementing a prototype of a new signal handling mechanism. The idea needs some fleshing out before it might be merged into the kernel, but it has attracted a certain amount of interest among the developers.

The patch adds a new sigfd() system call:

    int sigfd(sigset_t *mask, unsigned long flags);

The system call returns a file descriptor which will report on the set of signals found in the given mask (the flags argument is not used for now). A process reading from the file descriptor will receive a structure describing one signal which was delivered to the process; it will block if there are no outstanding signals.

This approach offers some advantages. Since signals are queued up and read one at a time, they can be dealt with in an orderly manner. The user-space application need not worry about races between signal handlers and other code. The signal file descriptor can also be used with the select() and poll() system calls, allowing signal handling to be folded into application event processing loops. An application can even pass the file descriptor to another process, should there be, for some reason, a desire to let that other process listen in on the first process's signals.

There was some immediate discussion of expanding this interface into a more generic event-handling mechanism. For example, timer events, asychronous I/O events, etc. could also be delivered via the same file descriptor. Linus stated that, to an extent, expanding the interface is what the flags argument was intended for. He doesn't want to put too much into this interface, however:

I'm not in the least interested in some "generic event" mechanism, and it's not where I think this should even go. This was very much about signals, and while I can see the potential to extend the notion of signals to things like timers, I don't think it's necessarily a good idea to extend it too far

Looking at the patch, a few developers commented on how much of it is really just boilerplate filesystem and inode code. It has to be there to make the file descriptor work, but really has little to do with the task at hand. Much of that code is duplicated with other subsystems which have to make "virtual" file descriptors. Davide Libenzi responded to this observation with a patch implementing a new, shared, "virtual filesystem" capability. If some variant of that patch goes in, it has the potential of ridding the kernel of a fair amount of tedious and error-prone code duplication.

(Log in to post comments)