PREV_LECNEXT_LEC

What You Will Learn

Prerequisites

Two Ways Processes Can Talk

Every IPC mechanism on Linux boils down to one of two underlying strategies:

1. Copy the data. The kernel moves bytes from the sending process’s memory into a kernel-managed holding area, then later copies those bytes out into the receiving process’s memory. This is what FIFOs, sockets, and message queues all do. It costs two copies per message but requires no synchronization primitives beyond what the kernel already provides.
2. Share the memory. A single region of physical memory is mapped into the address space of two or more processes at once. No copying happens after the initial setup, but now the processes must coordinate access themselves, usually with a semaphore or mutex, or they will corrupt each other’s writes.

This lecture covers the first strategy. The next lecture in this series covers POSIX shared memory, the second strategy.

FIFOs (Named Pipes)

A FIFO — short for First In, First Out — is what most people call a named pipe. It is the same mechanism the shell uses internally when you write command1 | command2, except a FIFO has a name on the filesystem so unrelated processes can open it, not just a parent and its child.

Create one with mkfifo(1) or the mkfifo(3) library call. Once created, it behaves like any other file for permission purposes: whoever has read or write access to the FIFO’s inode can use it. Internally, though, no data is ever stored on disk — the FIFO is backed entirely by an in-kernel buffer.

Because a FIFO has no message boundaries, the reader has to agree with the writer on a framing convention — newline-delimited text, a fixed record size, or a length-prefixed protocol are the three common choices.

Unix Domain Sockets

Unix domain sockets use the familiar Berkeley sockets API (socket(), bind(), connect(), accept()) but with address family AF_UNIX instead of AF_INET. Traffic never touches a network stack — it’s routed entirely inside the kernel — which makes them faster and simpler to secure than loopback TCP for local IPC.

They come in two flavours:

An important and often-missed detail: Unix domain datagrams are reliable — unlike UDP over IP, they are not silently dropped or reordered by the local kernel, since there’s no real network in the path. Maximum datagram size is governed by /proc/sys/net/core/wmem_max and is commonly 200 KiB or more on modern distributions — always check the live value on your target rather than assuming a fixed number.

POSIX Message Queues

POSIX message queues are the only mechanism in this group with a built-in concept of priority. Each message carries an integer priority (0 to MQ_PRIO_MAX, typically 32768), and the queue always delivers the highest-priority message first; messages of equal priority are delivered in FIFO order.

Queues are named starting with a single leading / and no further slashes — for example /ep-sensor-queue. They live in a pseudo-filesystem of type mqueue, which on most distributions you can inspect directly:

$ mount -t mqueue
mqueue on /dev/mqueue type mqueue (rw,relatime)
$ ls /dev/mqueue
ep-sensor-queue

Key tunables live under /proc/sys/kernel/:

Because the queue descriptor returned by mq_open(3) is a normal file descriptor, you can multiplex it with poll(2), select(2), or epoll(2) alongside sockets and other file descriptors in the same event loop — a detail that makes message queues a clean fit for embedded event-driven designs.

Comparison Table

Hands-On: A POSIX Message Queue Demo

Let’s build a tiny two-program demo: ep_mq_sender pushes a few priority-tagged messages into a queue, and ep_mq_receiver drains them, proving that higher-priority messages arrive first regardless of send order.

/* ep_mq_common.h */
#ifndef EP_MQ_COMMON_H
#define EP_MQ_COMMON_H

#define EP_QUEUE_NAME   "/ep-demo-queue"
#define EP_MAX_MSG_SIZE 256
#define EP_MAX_MSGS     10

#endif

/* ep_mq_sender.c */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <mqueue.h>
#include <fcntl.h>
#include <sys/stat.h>
#include "ep_mq_common.h"

int main(void)
{
    struct mq_attr attr = {
        .mq_flags   = 0,
        .mq_maxmsg  = EP_MAX_MSGS,
        .mq_msgsize = EP_MAX_MSG_SIZE,
        .mq_curmsgs = 0,
    };

    mqd_t mq = mq_open(EP_QUEUE_NAME, O_CREAT | O_WRONLY, 0644, &attr);
    if (mq == (mqd_t)-1) {
        perror("mq_open");
        return 1;
    }

    /* Sent in this order, priority given last: low, high, medium */
    mq_send(mq, "low-priority reading",    strlen("low-priority reading"),    1);
    mq_send(mq, "URGENT: overtemp alert",  strlen("URGENT: overtemp alert"),  9);
    mq_send(mq, "routine status update",   strlen("routine status update"),  5);

    printf("ep_mq_sender: 3 messages queued\n");
    mq_close(mq);
    return 0;
}

/* ep_mq_receiver.c */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <mqueue.h>
#include <fcntl.h>
#include "ep_mq_common.h"

int main(void)
{
    mqd_t mq = mq_open(EP_QUEUE_NAME, O_RDONLY);
    if (mq == (mqd_t)-1) {
        perror("mq_open");
        return 1;
    }

    char buf[EP_MAX_MSG_SIZE];
    unsigned int prio;

    for (int i = 0; i = 0) {
            buf[n] = '\0';
            printf("received (priority %u): %s\n", prio, buf);
        }
    }

    mq_close(mq);
    mq_unlink(EP_QUEUE_NAME);
    return 0;
}

Build and Run

$ gcc -o ep_mq_sender ep_mq_sender.c -lrt
$ gcc -o ep_mq_receiver ep_mq_receiver.c -lrt
$ ./ep_mq_sender
ep_mq_sender: 3 messages queued
$ ./ep_mq_receiver
received (priority 9): URGENT: overtemp alert
received (priority 5): routine status update
received (priority 1): low-priority reading

Notice the receive order: priority 9 first, then 5, then 1 — completely independent of the send order. That’s the priority-then-age ordering guarantee POSIX message queues give you, and it’s the one feature none of the other mechanisms in this lecture offer natively.

Common Mistakes and Troubleshooting

Best Practices

Performance Considerations

All three mechanisms in this lecture pay a two-copy cost per message: once into the kernel, once back out. For small, infrequent control messages — configuration changes, status events, alerts — this overhead is negligible. If you find yourself streaming large buffers (camera frames, audio blocks) at high rates through a FIFO or socket, that’s usually a sign you actually want shared memory, covered in the next lecture, with a small message-queue “doorbell” to signal when new data is ready.

Security Considerations

FIFOs and Unix sockets are protected by ordinary filesystem permissions on their path — set the owning user/group and mode deliberately rather than leaving them world-writable. POSIX message queue names are not filesystem paths in the traditional sense but are still subject to permission checks at mq_open time via the mode argument; audit that mode the same way you would a file’s permission bits.

Summary and Key Takeaways

Conclusion

Choosing between a FIFO, a Unix socket, and a POSIX message queue isn’t about which one is “best” — it’s about matching the mechanism’s guarantees to what your application actually needs. If you need priority-ordered delivery, message queues win outright. If you need a familiar, flexible, bi-directional channel, Unix sockets are the safe default. And if you just need the simplest possible one-way pipe between two processes you control, a FIFO gets the job done with almost no code. In the next lecture, we move to the second IPC strategy entirely: sharing memory directly, and the synchronization discipline that comes with it.

Frequently Asked Questions

PREV_LECNEXT_LEC