Some thinking out loud about signals

The problem with signals: you never know when they're delivered. They are completely asynchronous, so delivery may happen before the next system call is made as well as while inside the system call.

This means that a setup where you test for a signal flag that's incremented by a handler, just before going into a blocking call such as select(), has a nasty race: the handler may have been called and the flag incremented just after the test, but before the select.

If that happens, select() won't be interrupted, because the signal has already been handled as far as the kernel is concerned. And for sure, doing a test closer to the select doesn't solve the race condition.

Using blocking masks is no solution either: although signal delivery is deferred till the unmasking call, it can still happen after the unmasking and handling, but before the select().

As far as I can see, there are three obvious solutions to this problem:

• A technique I used earlier: make the sighandler write to a pipe that's included in the select set. This is OK as long as you make sure the pipe is nonblocking (otherwise the sighandler can block if called often enough before the pipe is emptied). That has the implication however that one or more sighandler invocations may go undetected by the main program.

  This doesn't have to be much of a problem, as long as the condition doesn't last too long and the exact number of handler invocations doesn't matter. In most cases it won't, eg. when a SIGCHLD is delivered, any number of childs may actually have exited, so you already have to loop through wait4(WNOHANG) anyway until no more dead childs are found.

  However, if we don't use a separate pipe for every signal but want to use the data in the pipe to tell which signal occurred, we may remain unaware of a particular pending signal when we're flooded by others. That's not very attractive.

• Don't use sighandlers at all; set all non-IGN/DFL handlers to an empty handler that does nothing but reinstall the handler, and keep their delivery blocked using sigprocmask. At the point in the main program where you want to test for delivered signals, you use use sigpending to find out which were.

  By briefly unblocking and re-blocking delivery, you effectively clear all pending signals (whether they had been handled or not).

  This does create a race that can cause an event to be missed, between the sigpending() test and the re-blocking of delivery. No good.

• Do all the work within the signal handler itself, and protect all sections in the main program in which this work may not be carried out, using a sigprocmask.

  This is possible, but quite risky and I'd rather do the opposite: signals are delived nowhere but at the exact location in the main program where I want to handle them. Also because I don't want to have to expose the program's full state through global variables just so that a signal handler can do its work.

The other option is the last one, but as it limits control and requires the work associated with signals to happen in an isolated function (the signal handler), it's isn't very attractive either.

Requirements

It seems that what we want from a real solution is this:

1. It must be possible to interrupt blocking syscalls and do what's needed before restarting them. In other words, handling signalled events should not be deferred until some other event happens that unblocks the syscall.

   This implies that the signal must either be unmasked during those syscalls, or that the pipe-solution is used - although that only works when select is the only blocking syscall.

2. The exact number of invocations of a handler that happened between the last test and the next one isn't important, but it must always be possible to distinguish between zero and more calls.

   It must be possible to test and clear this difference atomically at a particular point in the main program.

   This implies that any masking/unmasking trick won't work: there's always the period after the test, before the masking that effectively queues the signal in the pending set.
    

As said, using a pipe as the queue is attractive as it also solves the problem of interrupting select even though the signal is already delivered when we enter it, by including the reading end in the select. However, there's still the risk of overflowing and missing signals.

Still, the pipe must always have something in it as long as the event hasn't been completely handled and cleared yet, or select will block.

Solution

What if we do it like this: the signal handler empties the pipe first and then writes a byte to it. To all parties concerned, this appears to happen atomically; a signal handler won't interrupt itself (well, we can prevent it on systems that have sigaction()), and surely the main program can never interrupt the signal handler.

That means that the firstmost byte in the pipe is the actual 'signalled' flag. This can never not be set when the handler was actually called.

As long as this flag is set, select() will always exit immediately if you include the reading end of the pipe. And, testing and resetting 'atomically' (as far as the handler is concerned) can be done by reading the single byte from it in non-blocking mode.

If the read returns no data, there's nothing to be done. If read returns something else, we just tested and cleared the flag (which is the existence of the data byte in the pipe) atomically.

The atomicity comes from the fact that if a reading end of a pipe has two readers (effectively, the signal handler that empties it and puts it back, and the main program), a byte present in it has to go either to one or the other, but it can never disappear, or go to both.

Ok!

Now we want to refine the technique a bit, as we want to know which signals are in the set. The idea is this:

Instead of a byte, we use a 32-bit value or even a real sigset_t that holds the 'pending since last test' set in the pipe.

The signal handler, when called, 'empties' the pipe by reading the word (using zero if the pipe didn't have any data), OR'ing the received signal into it and writing it back.

The main program needs to ensure that the read in the signal handler doesn't interfere with the read that it uses to test-and-clear the set. This used to be easy because of the single byte, but if two processes each attempt to read four bytes from a pipe, you can't guarantee that one doesn't gets a short read of two, causing the other two bytes to go to the other.

But if the main process temporarily blocks signal delivery using sigprogmask around the nonblocking read, we're done.

This way, unhandled signals will cause select() to exit immediately, while the main program can do an atomic test-and-clear to handle them at any desired place, without any races!