FIFOs — Named Pipes

Chapter 1: Creating a FIFO

Since a FIFO is a special file on disk, you have to create it before any process can open it. There are two ways: from your C code with mknod(), or from the command line with mkfifo.

c
/* Create a FIFO from C code */
mknod("myfifo", S_IFIFO | 0644, 0);

The first argument is the filename. The second is the creation mode: S_IFIFO tells the kernel "make this a FIFO" and 0644 sets read/write permissions (just like chmod). The third argument is a device number — ignored for FIFOs, so pass 0.

From the command line, it's even simpler:

shell
$ mkfifo myfifo
$ ls -l myfifo
prw-r--r--  1 beej  beej  0 Jan 1 00:00 myfifo

Notice the p at the start of the permissions — that means "pipe." The file has zero bytes because FIFOs don't store data on disk. They're conduits, not containers.

Chapter 2: speak.c — The Writer

Let's build Beej's classic producer-consumer example. The writer process (speak.c) creates the FIFO and sends data into it. Here's the code:

c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <unistd.h>

#define FIFO_NAME "american_maid"

int main(void)
{
    char s[300];
    int num, fd;

    mknod(FIFO_NAME, S_IFIFO | 0666, 0);

    printf("waiting for readers...\n");
    fd = open(FIFO_NAME, O_WRONLY);    /* BLOCKS here */
    printf("got a reader--type some stuff\n");

    while (fgets(s, 300, stdin) != NULL) {
        if ((num = write(fd, s, strlen(s))) == -1)
            perror("write");
        else
            printf("speak: wrote %d bytes\n", num);
    }
    return 0;
}

Notice that mknod() is called every time. If the FIFO already exists, mknod() fails silently (returns -1 with errno set to EEXIST), which is fine — the FIFO is already there.

Chapter 3: tick.c — The Reader

Now the consumer side. tick.c opens the same FIFO for reading and sucks out whatever speak puts in:

c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <unistd.h>

#define FIFO_NAME "american_maid"

int main(void)
{
    char s[300];
    int num, fd;

    mknod(FIFO_NAME, S_IFIFO | 0666, 0);

    printf("waiting for writers...\n");
    fd = open(FIFO_NAME, O_RDONLY);     /* BLOCKS here */
    printf("got a writer\n");

    do {
        if ((num = read(fd, s, 300)) == -1)
            perror("read");
        else {
            s[num] = '\0';
            printf("tick: read %d bytes: \"%s\"\n", num, s);
        }
    } while (num > 0);

    return 0;
}

The key sequence is: start speak in one terminal (it blocks on open), then start tick in another (it also blocks on open). The moment both sides are open, data flows. Type in the speak window, and tick prints it out.

Chapter 4: Blocking Behavior

By default, FIFOs block in two situations, and this blocking is the core synchronization mechanism:

After both sides are connected:

• read() blocks when the FIFO is empty but writers still exist — it waits for data.
• write() blocks when the FIFO buffer is full — it waits for the reader to drain some data.

This makes FIFOs self-synchronizing. The producer and consumer naturally pace each other, like a conveyor belt that pauses when either end stops.

Chapter 5: O_NDELAY — Non-Blocking Mode

Sometimes you don't want open() to block. Maybe you want to check if a reader/writer exists without freezing your whole program. The O_NDELAY flag (also called O_NONBLOCK) changes the blocking behavior:

c
/* Non-blocking open for reading */
fd = open(FIFO_NAME, O_RDONLY | O_NDELAY);

The effects depend on which side you're on:

Chapter 6: Multiple Writers

Here's something pipes can't do: multiple unrelated processes can write to the same FIFO. Since the FIFO is a file on disk, any process with the right permissions can open it.

Start one tick (reader) and two or three speaks (writers) in different terminals. Type in any writer window, and the reader gets all the messages. When one writer exits, the reader keeps going — it only gets EOF when all writers close their end.

What about multiple readers? That gets weird. Sometimes one reader gets everything, sometimes messages alternate unpredictably between readers. The kernel doesn't guarantee fair distribution. In practice, you usually want a single reader.

Chapter 7: FIFO Producer-Consumer Simulator

Watch messages flow through a named pipe. Multiple producers can feed into the FIFO, and the consumer reads them in order. Notice how data arrives in FIFO order regardless of which producer sent it.

Chapter 8: Beyond FIFOs

FIFOs solve the "unrelated processes" problem that pipes couldn't. But they're still just byte streams — there's no concept of message boundaries or types. If you need to send structured, typed messages with priority retrieval, you want message queues.

"Having the name of the pipe right there on disk sure makes it easier, doesn't it?" — Beej