Porting Windows-Centric Console I/O To Linux

Question

I am developing a Windows application that has a separate thread for processing user (or 3rd party) application input via stdin.

This thread is designed such that it waits via WaitForMultipleObjects on two events:

1. A death signal. When this signal is raised, the interface-processing thread shuts down.
2. An interface signal. When this signal is raised, there is input ready to be read. The input is read and processed.

Under Windows this thread enters a main loop where it Waits for these 2 events (where bWaitAll is FALSE). Waiting on the stdin handle has the effect of signaling when there is input ready to be read, and the other event is set from elsewhere in the application.

This works exactly as I want. It waits for an event to be raised without entering in to a busy-wait, and it waits for both event simutaneously.

I wish to port this functionality to Linux, but I'm not sure how to achieve the desired result. Fundamentally, what I really want is this:

Under Linux, how do I design a thread so that it will respond immediately to user-input on stdin, yet it can also respond immediately to a kill-flag being raised from elsewhere in the application?

In order to accomplish the latter, it seems to me that I cannot use cin, gets, getch or any other function that blocks until the user has entered text. Yet I do not know how to read user input in a console-based application without blocking.

I'm open to any change in architecture (if there's a more Linux-y way to do this) that include having user input processed in a separate thread that can be terminated from elsewhere in the application. I'm using GCC 4.4, and Boost 1.51.

Answer 1

The standard way of doing this in Linux is to use the select(2) system call. However, select is more limited than WaitForMultipleObjects, in that it can only wait on file descriptors, not other kinds of objects (such as events). So, the typical way of working around that is to create a pipe and write a dummy value to the pipe as your "signal".

Something like this:

// Error checking omitted for expository purposes
int pipefd[2];
pipe(pipefd);  // Create the pipe

while(1)
{
    // Create file descriptor set of stdin and the read end of the pipe
    fd_set fds;
    FD_ZERO(&fds);
    FD_SET(STDIN_FILENO, &fds);
    FD_SET(pipefd[0], &fds);
    int maxfd = MAX(STDIN_FILENO, pipefd[0]);

    // Wait until input becomes available on either stdin or the pipe
    int num_available = select(&fds, NULL, NULL, NULL);

    // Read & process stdin if possible (will not block)
    if (FD_ISSET(STDIN_FILENO, &fds))
    {
        int n = read(STDIN_FILENO, buffer, size);
        ...
    }

    // Read & process pipe if possible (will not block)
    if (FD_ISSET(pipefd[0], &fds))
    {
        char dummy;
        read(pipefd[0], &dummy, 1);
        // Handle signal (e.g. break out of loop)
    }
}

Then to signal to the thread that it's done, just write a single byte to the write end of the pipe:

char dummy = 42;
write(pipefd[1], &dummy, 1);

Answer 2

libev (and several similar incarnations) offers a convenient abstraction around select including being able to pend on signals.

If you have the option to alter the origin of "An interface signal" then you could consider changing it to use raise instead.