pselect() on Linux does not deliver signals if events are pending

Question

I'm trying to add a signal handler for proper cleanup to my event-driven application.

My signal handler for SIGINT only changes the value of a global flag variable, which is then checked in the main loop. To avoid races, the signal is blocked at all times, except during the pselect() call. This should cause pending signals to be delivered only during the pselect() call, which should be interrupted and fail with EINTR.

This usually works fine, except if there are already events pending on the monitored file descriptors (e.g. under heavy load, when there's always activity on the file descriptors).

This sample program reproduces the problem:

#include <assert.h>
#include <errno.h>
#include <stdbool.h>
#include <stdio.h>
#include <string.h>

#include <sys/select.h>
#include <fcntl.h>
#include <signal.h>
#include <unistd.h>

volatile sig_atomic_t stop_requested = 0;

void handle_signal(int sig)
{
    // Use write() and strlen() instead of printf(), which is not async-signal-safe
    const char * out = "Caught stop signal. Exiting.\n";
    size_t len = strlen (out);
    ssize_t writelen = write(STDOUT_FILENO, out, len);
    assert(writelen == (ssize_t) len);
    stop_requested = 1;
}

int main(void)
{
    int ret;

    // Install signal handler
    {
        struct sigaction sa;
        memset(&sa, 0, sizeof(sa));
        sa.sa_handler = handle_signal;
        ret = sigaction(SIGINT, &sa, NULL);
        assert(ret == 0);
    }

    // Block SIGINT
    sigset_t old_sigmask;
    {
        sigset_t blocked;
        sigemptyset(&blocked);
        sigaddset(&blocked, SIGINT);
        ret = sigprocmask(SIG_BLOCK, &blocked, &old_sigmask);
        assert(ret == 0);
    }

    ret = raise(SIGINT);
    assert(ret == 0);

    // Create pipe and write data to it
    int pipefd[2];
    ret = pipe(pipefd);
    assert(ret == 0);
    ssize_t writelen = write(pipefd[1], "foo", 3);
    assert(writelen == 3);

    while (stop_requested == 0)
    {
        printf("Calling pselect().\n");

        fd_set fds;
        FD_ZERO(&fds);
        FD_SET(pipefd[0], &fds);
        struct timespec * timeout = NULL;
        int ret = pselect(pipefd[0] + 1, &fds, NULL, NULL, timeout, &old_sigmask);
        assert(ret >= 0 || errno == EINTR);
        printf("pselect() returned %d.\n", ret);

        if (FD_ISSET(pipefd[0], &fds))
            printf("pipe is readable.\n");

        sleep(1);
    }
    printf("Event loop terminated.\n");
}

This program installs a handler for SIGINT, then blocks SIGINT, sends SIGINT to itself (which will not be delivered yet because SIGINT is blocked), creates a pipe and writes some data into the pipe, and then monitors the read end of the pipe for readability.

This readability monitoring is done using pselect(), which is supposed to unblock SIGINT, which should then interrupt the pselect() and call the signal handler.

However, on Linux (I tested on 5.6 and 4.19), the pselect() call returns 1 instead and indicates readability of the pipe, without calling the signal handler. Since this test program does not read the data that was written to the pipe, the file descriptor will never cease to be readable, and the signal handler is never called. In real programs, a similar situation might arise under heavy load, where a lot of data might be available for reading on different file descriptors (e.g. sockets).

On the other hand, on FreeBSD (I tested on 12.1), the signal handler is called, and then pselect() returns -1 and sets errno to EINTR. This is what I expected to happen on Linux as well.

Am I misunderstanding something, or am I using these interfaces incorrectly? Or should I just fall back to the old self-pipe trick, which (I believe) would handle this case better?

Answer 1

This is a type of resource starvation caused by always checking for active resources in the same order. When resources are always checked in the same order, if the resources checked first are busy enough the resources checked later may never get any attention.

See What is starvation?.

The Linux implementation of pselect() apparently checks file descriptors before checking for signals. The BSD implementation does the opposite.

For what it's worth, the POSIX documentation for pselect() states:

If none of the selected descriptors are ready for the requested operation, the pselect() or select() function shall block until at least one of the requested operations becomes ready, until the timeout occurs, or until interrupted by a signal.

A strict reading of that description requires checking the descriptors first. If any descriptor is active, pselect() will return that instead of failing with errno set to EINTR.

In that case, if the descriptors are so busy that one is always active, the signal processing gets starved.

The BSD implementation likely starves active descriptors if signals come in too fast.

One common solution is to always process all active resources every time a select() call or similar returns. But you can't do that with your current design that mixes signals with descriptors because pselect() doesn't even get to checking for a pending signal if there are active descriptors. As @Shawn mentioned in the comments, you can map signals to file descriptors using signalfd(). Then add the descriptor from signalfd() to the file descriptor set passed to pselect().