Pipes - Learning Module

Loading content...

0/227

Unidirectional Communication

The One-Way Street

Imagine a water pipe in your home. Water flows from the supply into your faucet—never back out the same way. You cannot send water upstream to the water treatment plant through your sink. This physical reality is no accident; it's the most natural model for efficient flow.

Anonymous pipes follow exactly the same principle. Data enters through the write end and exits through the read end—always in one direction, never backwards, never bidirectionally through the same pipe. This constraint, far from being a limitation, is a carefully chosen design decision that enables the simplicity, efficiency, and robustness that make pipes so powerful.

In this page, we explore unidirectional communication in depth: why it exists, what benefits it provides, how it shapes pipe-based programming, and how sophisticated patterns emerge from respecting rather than fighting this constraint.

What You Will Learn

By the end of this page, you will understand why pipes are unidirectional by design, how this simplifies synchronization, the implications for buffer management, the patterns for handling directional constraints, and how this design philosophy permeates all of Unix IPC.

The Rationale for Unidirectionality

Why design pipes to be unidirectional when bidirectional communication seems more flexible? The answer lies in the profound simplification that single-direction flow provides across multiple dimensions.

1. Simplified Buffer Management

With unidirectional flow, the pipe buffer is a simple FIFO queue:

Data enters at the tail (write)
Data exits at the head (read)
No complex indexing or partitioning needed

A bidirectional buffer would require:

Separate regions for each direction
Independent head/tail pointers for each direction
Careful management to prevent one direction from starving the other
More complex locking to prevent races

2. Eliminated Deadlock Classes

Consider a bidirectional channel between processes A and B:

A writes data expecting B to process and respond
B writes data expecting A to process and respond
Both are waiting to write while neither is reading
Deadlock!

With unidirectional pipes, this class of deadlock vanishes. One process writes, the other reads—roles are clear and non-conflicting.

Unidirectional Benefits

•Simple FIFO buffer management
•Single mutex sufficient for synchronization
•No buffer partitioning complexity
•Clear producer/consumer roles
•Eliminated write-write deadlocks
•Trivial EOF semantics
•Natural pipeline composition

Bidirectional Complexities

•Dual buffer regions needed
•Multiple locks for each direction
•Buffer starvation possible
•Role confusion (who reads when?)
•Deadlock-prone without careful design
•Complex EOF/close semantics
•Harder to compose in pipelines

3. Natural Fit for Pipelines

The shell pipeline model (A | B | C | D) maps perfectly to unidirectional pipes:

Each stage reads from upstream, writes downstream
Stages are independent—they don't know who's on either side
Backpressure propagates naturally through blocking
Adding or removing stages doesn't change semantics

Bidirectional channels would make pipelines far more complex. How would process B know whether incoming data is from A (to process) or C (a response)? The clean linear topology depends on unidirectional semantics.

4. Simplicity Is a Feature

Unix philosophy values simple, composable primitives over complex, do-everything solutions. A unidirectional pipe is the simplest possible IPC mechanism. For bidirectional needs, you compose two pipes—explicit, clear, debuggable. The system provides orthogonal building blocks; you assemble them as needed.

Design Philosophy

The choice of unidirectional pipes reflects the Unix philosophy of 'do one thing well.' A pipe moves data from A to B. If you need data from B to A also, create another pipe. This explicitness prevents subtle bugs and makes data flow visible in your code.

Data Flow Mechanics in Detail

Let's examine exactly how data flows through a unidirectional pipe, tracing the journey from user-space write to user-space read:

The Write Path:

When a process calls write(pipefd[1], data, length):

System Call Entry — Process transitions to kernel mode
Pipe Validation — Kernel verifies fd refers to a pipe write end
Reader Check — If no readers exist (readers = 0), SIGPIPE/EPIPE returned
Lock Acquisition — Kernel acquires the pipe mutex
Space Check — If buffer has room, proceed; otherwise:
- Add process to write wait queue
- Release mutex and sleep
- Wake when space available, re-acquire mutex
Data Copy — Copy bytes from user space to kernel pipe buffer
Update Pointers — Move write pointer (head) forward
Wake Readers — Notify waiting readers that data is available
Release Lock — Release mutex
Return — Return bytes written to user space

data_flow_trace.txt
┌─────────────────────────────────────────────────────────────────────────┐
│              UNIDIRECTIONAL DATA FLOW TRACE                              │
└─────────────────────────────────────────────────────────────────────────┘
 
WRITER PROCESS                                     READER PROCESS
═══════════════                                    ════════════════
 
    write(fd[1], "DATA", 4)                        read(fd[0], buf, 128)
         │                                              │
         ▼                                              ▼
┌─────────────────────┐                    ┌─────────────────────┐
│ 1. Trap to kernel   │                    │ 1. Trap to kernel   │
│ 2. Validate fd      │                    │ 2. Validate fd      │
│ 3. Check readers>0  │                    │ 3. Check writers>0  │
│ 4. Acquire mutex    │                    │ 4. Acquire mutex    │
└──────────┬──────────┘                    └──────────┬──────────┘
           │                                          │
           ▼                                          ▼
    ┌──────────────────────────────────────────────────────────┐
    │                    KERNEL PIPE BUFFER                     │
    │          (protected by single mutex)                      │
    │                                                           │
    │   ┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐      │
    │   │   │   │   │   │   │ D │ A │ T │ A │   │   │   │      │
    │   └───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘      │
    │                        ▲           ▲                      │
    │                  tail  │           │ head                 │
    │                 (read) │           │ (write)              │
    │                        │           │                      │
    │   Data flows: ════════════════════════════►               │
    │               LOW addresses → HIGH addresses               │
    └──────────────────────────────────────────────────────────┘
           │                                          │
           ▼                                          ▼
┌─────────────────────┐                    ┌─────────────────────┐
│ 5. Copy data in     │                    │ 5. Copy data out    │
│ 6. Update head      │                    │ 6. Update tail      │
│ 7. Wake readers     │                    │ 7. Wake writers     │
│ 8. Release mutex    │                    │ 8. Release mutex    │
│ 9. Return count     │                    │ 9. Return count     │
└─────────────────────┘                    └─────────────────────┘
         │                                          │
         ▼                                          ▼
    Returns: 4                                 Returns: 4
    (bytes written)                            (bytes read)
 
    ═══════════════════════════════════════════════════════════
    KEY INVARIANTS:
    ═══════════════════════════════════════════════════════════
    1. Data exits in same order it entered (FIFO)
    2. No data duplication (each byte read once, then gone)
    3. No data loss (all written bytes eventually readable)
    4. Flow is strictly: WRITE END ───► READ END

The Read Path:

When a process calls read(pipefd[0], buffer, size):

System Call Entry — Process transitions to kernel mode
Pipe Validation — Kernel verifies fd refers to a pipe read end
Lock Acquisition — Kernel acquires the pipe mutex
Data Check — If buffer has data, proceed; otherwise:
- If no writers exist (writers = 0), return 0 (EOF)
- Add process to read wait queue
- Release mutex and sleep
- Wake when data available, re-acquire mutex
Data Copy — Copy bytes from kernel buffer to user space
Update Pointers — Move read pointer (tail) forward
Wake Writers — Notify waiting writers that space is available
Release Lock — Release mutex
Return — Return bytes read to user space

The Simplifying Effect:

Notice how this unidirectional model needs only:

One mutex (not two)
One buffer region (not partitioned)
Simple head/tail pointers (not complex indexing)
Clear wait queues (readers wait for data, writers wait for space)

This simplicity directly translates to performance and reliability.

Blocking Semantics and Flow Control

Unidirectional pipes implement implicit flow control through blocking. This mechanism automatically balances producers and consumers without requiring explicit coordination.

When Writers Block:

A write() call blocks when:

The pipe buffer is full
Readers exist but haven't consumed data

This prevents unbounded buffering—writers cannot run arbitrarily ahead of readers. Memory is bounded, and faster producers naturally slow down to match slower consumers.

When Readers Block:

A read() call blocks when:

The pipe buffer is empty
Writers exist but haven't produced data

This prevents busy-waiting—readers don't spin checking for data. They sleep efficiently until data arrives.

Why This Matters:

Blocking Behavior Summary
Condition	write() Behavior	read() Behavior
Buffer has space, has data	Writes immediately, returns byte count	Reads immediately, returns byte count
Buffer full	Blocks until space available	Reads immediately (returns available)
Buffer empty	Writes immediately	Blocks until data available
No readers (readers = 0)	SIGPIPE (or EPIPE)	N/A (would be read end)
No writers (writers = 0)	N/A (would be write end)	Returns 0 (EOF)

Implicit Backpressure:

The blocking behavior creates automatic backpressure through the pipeline:

[Fast Producer] ──▶ [Pipe 1] ──▶ [Slow Consumer] ──▶ [Pipe 2] ──▶ [Output]
                      │
              Buffer fills up
                      │
              Producer blocks
                      │
              System naturally balances

Without any explicit signaling:

If the consumer is slow, its input pipe fills up
The upstream producer blocks on write()
That producer's input pipe fills up
The pattern propagates backward through the pipeline
Eventually the original source slows to the rate of the slowest stage

This automatic balancing is why pipelines don't need explicit flow control. The operating system provides it transparently through blocking semantics.

blocking_demonstration.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/wait.h>
#include <errno.h>
 
/**
 * Demonstrates blocking behavior in unidirectional pipes.
 * 
 * The writer tries to write more data than the buffer can hold,
 * causing it to block until the reader consumes data.
 */
int main(void) {
    int pipefd[2];
    pid_t pid;
    
    // Create pipe (typically 64KB buffer)
    if (pipe(pipefd) == -1) {
        perror("pipe");
        exit(EXIT_FAILURE);
    }
    
    pid = fork();
    if (pid == -1) {
        perror("fork");
        exit(EXIT_FAILURE);
    }
    
    if (pid == 0) {
        // CHILD: Slow reader
        close(pipefd[1]);
        
        char buffer[1024];
        ssize_t total = 0;
        ssize_t n;
        
        while ((n = read(pipefd[0], buffer, sizeof(buffer))) > 0) {
            total += n;
            printf("[Child] Read %zd bytes (total: %zd)\n", n, total);
            
            // Simulate slow consumer (100ms per read)
            usleep(100000);
        }
        
        printf("[Child] EOF reached. Total bytes: %zd\n", total);
        close(pipefd[0]);
        exit(EXIT_SUCCESS);
    }
    
    // PARENT: Fast writer
    close(pipefd[0]);
    
    // Try to write 256KB (4x typical buffer size)
    const size_t total_to_write = 256 * 1024;
    char *data = malloc(total_to_write);
    memset(data, 'X', total_to_write);
    
    size_t written = 0;
    while (written < total_to_write) {
        ssize_t n = write(pipefd[1], data + written, total_to_write - written);
        if (n == -1) {
            if (errno == EPIPE) {
                printf("[Parent] Reader closed pipe.\n");
                break;
            }
            perror("write");
            break;
        }
        written += n;
        printf("[Parent] Wrote %zd bytes (total: %zu)\n", n, written);
        // Note: Most writes will block waiting for reader to consume!
    }
    
    printf("[Parent] Finished writing. Closing pipe.\n");
    close(pipefd[1]);
    free(data);
    
    waitpid(pid, NULL, 0);
    return 0;
}

Observe Blocking in Action

Run the above program and observe the timing. The parent's writes will pause (block) whenever the buffer fills, waiting for the slow child to read. This automatic coordination requires no explicit synchronization in your code—the kernel handles it through unidirectional pipe semantics.

Non-Blocking Mode: O_NONBLOCK

While blocking behavior is the default and often desirable, there are scenarios where blocking is unacceptable:

Event-driven architectures — A main loop handling multiple sources
Timeouts — Need to give up after waiting too long
Multiplexing — Monitoring many file descriptors simultaneously
Real-time systems — Cannot tolerate unbounded delays

For these cases, pipes support non-blocking mode via the O_NONBLOCK flag.

Setting Non-Blocking Mode:

nonblocking_pipe.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
#define _GNU_SOURCE
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
 
// Method 1: Using pipe2() (Linux-specific, atomic)
int create_nonblocking_pipe_modern(int pipefd[2]) {
    return pipe2(pipefd, O_NONBLOCK | O_CLOEXEC);
}
 
// Method 2: Using fcntl() (portable, non-atomic)
int set_nonblocking(int fd) {
    int flags = fcntl(fd, F_GETFL);
    if (flags == -1) return -1;
    
    return fcntl(fd, F_SETFL, flags | O_NONBLOCK);
}
 
int create_nonblocking_pipe_portable(int pipefd[2]) {
    if (pipe(pipefd) == -1) {
        return -1;
    }
    
    if (set_nonblocking(pipefd[0]) == -1 ||
        set_nonblocking(pipefd[1]) == -1) {
        close(pipefd[0]);
        close(pipefd[1]);
        return -1;
    }
    
    return 0;
}
 
// Using a non-blocking pipe
void nonblocking_example(int pipefd[2]) {
    char buffer[1024];
    
    // Non-blocking read: returns immediately even if no data
    ssize_t n = read(pipefd[0], buffer, sizeof(buffer));
    
    if (n == -1) {
        if (errno == EAGAIN || errno == EWOULDBLOCK) {
            // No data available right now, but pipe is valid
            printf("No data available (would block)\n");
            // ... do other work, try again later ...
        } else {
            perror("read error");
        }
    } else if (n == 0) {
        printf("EOF: all writers have closed\n");
    } else {
        printf("Read %zd bytes\n", n);
    }
    
    // Non-blocking write: returns immediately even if buffer full
    const char *data = "Hello";
    n = write(pipefd[1], data, 5);
    
    if (n == -1) {
        if (errno == EAGAIN || errno == EWOULDBLOCK) {
            // Buffer is full right now
            printf("Buffer full (would block)\n");
            // ... do other work, try again later ...
        } else if (errno == EPIPE) {
            printf("No readers (broken pipe)\n");
        } else {
            perror("write error");
        }
    } else {
        printf("Wrote %zd bytes\n", n);
    }
}

Non-Blocking Behavior:

Operation	Blocking Mode	Non-Blocking Mode
read(), empty buffer, writers exist	Blocks until data	Returns -1, errno = EAGAIN
read(), empty buffer, no writers	Returns 0 (EOF)	Returns 0 (EOF)
write(), full buffer, readers exist	Blocks until space	Returns -1, errno = EAGAIN
write(), readers gone	SIGPIPE/EPIPE	SIGPIPE/EPIPE

When to Use Non-Blocking:

With select()/poll()/epoll() — These multiplexing calls tell you when read/write won't block. Use non-blocking mode to handle edge cases.
Timeout-based operations — Check for data, do other work if unavailable, check again.
Avoiding priority inversion — In real-time systems where blocking could delay high-priority work.
Complex communication patterns — When a process must read from multiple sources or write to multiple destinations.

EAGAIN Is Not an Error

When using non-blocking pipes, EAGAIN (or equivalently, EWOULDBLOCK) is not a failure—it's normal operation indicating 'try again later.' Your code must be prepared to retry, not to treat it as a fatal error. This is a common source of bugs in non-blocking I/O code.

EOF Detection and Pipe Closure

In unidirectional communication, detecting end-of-stream is crucial. How does a reader know the writer is done? How does a writer know if there's still someone listening?

EOF From the Reader's Perspective:

The reader detects end-of-stream when:

All data in the buffer has been consumed
AND no write-end file descriptors remain open

At this point, read() returns 0 (zero bytes read). This is distinct from EAGAIN (would block) and from errors (-1).

The Critical Implication:

If ANY process holds the write end open, the reader will never see EOF. This is why closing unused pipe ends after fork is mandatory—not optional, not good practice, but mandatory for correctness.

eof_scenarios.txt
┌─────────────────────────────────────────────────────────────────────────┐
│              EOF DETECTION SCENARIOS                                     │
└─────────────────────────────────────────────────────────────────────────┘
 
SCENARIO 1: Proper EOF signaling (CORRECT)
══════════════════════════════════════════
 
Parent (Writer):                    Child (Reader):
                                    
  pipe()[0,1]                         (inherits both)
  fork()                              fork()
  close(fd[0])  ←── Close unused     close(fd[1])  ←── Close unused
  write(...)                          read(...) → data
  write(...)                          read(...) → data
  close(fd[1])  ←── Signal EOF       read(...) → 0 (EOF!) ✓
  wait()                              exit()
 
  Writers remaining: 1 → 0           Reader sees EOF when writers = 0
 
 
SCENARIO 2: Forgotten close (BUG!)
══════════════════════════════════════════
 
Parent (Writer):                    Child (Reader):
                                    
  pipe()[0,1]                         (inherits both)
  fork()                              fork()
  close(fd[0])                        ← fd[1] NOT closed (BUG!)
  write(...)                          read(...) → data
  write(...)                          read(...) → data
  close(fd[1])                        read(...) → BLOCKS FOREVER ✗
                                      
  Writers remaining: 1 → 0            Child still holds write end!
  BUT child holds fd[1]!              Writers = 1, so no EOF signaled
  
  RESULT: Deadlock - child blocks waiting for EOF that never comes
 
 
SCENARIO 3: SIGPIPE when readers gone (CORRECT)
══════════════════════════════════════════
 
Parent (Writer):                    Child (Reader):
                                    
  pipe()[0,1]                         (inherits both)
  fork()                              fork()
  close(fd[0])                        close(fd[1])
  write(...)                          read(...) → data
  ...                                 close(fd[0]) + exit()
  write(...) → SIGPIPE! ✓             
                                      
  Parent notified that no one         Readers = 0, so write fails
  is listening anymore

SIGPIPE From the Writer's Perspective:

The writer is notified when no readers remain through the SIGPIPE signal:

Default SIGPIPE action: terminate the process
If SIGPIPE is ignored/blocked: write() returns -1 with errno = EPIPE

This mechanism prevents writers from wasting resources producing data no one will consume. It's the write-end equivalent of EOF.

Proper Signal Handling:

sigpipe_handling.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <errno.h>
#include <string.h>
 
/**
 * Robust SIGPIPE handling for pipe writers.
 * 
 * Option 1: Ignore SIGPIPE, check for EPIPE
 * Option 2: Handle SIGPIPE to clean up gracefully
 */
 
// Option 1: Ignore SIGPIPE (most common approach)
void setup_ignore_sigpipe(void) {
    // Ignore SIGPIPE globally
    signal(SIGPIPE, SIG_IGN);
    
    // Now write() to a pipe with no readers returns -1 with errno = EPIPE
    // Instead of terminating the process
}
 
ssize_t safe_write(int fd, const void *buf, size_t count) {
    ssize_t result = write(fd, buf, count);
    
    if (result == -1 && errno == EPIPE) {
        // Pipe has no readers - handle gracefully
        fprintf(stderr, "Warning: Pipe reader has closed.\n");
        return -1;
    }
    
    return result;
}
 
// Option 2: Handle SIGPIPE for cleanup
volatile sig_atomic_t pipe_broken = 0;
 
void sigpipe_handler(int sig) {
    pipe_broken = 1;
    // Note: Cannot do complex operations in signal handler
    // Just set a flag and handle in main code
}
 
void setup_handle_sigpipe(void) {
    struct sigaction sa;
    sa.sa_handler = sigpipe_handler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;
    sigaction(SIGPIPE, &sa, NULL);
}
 
ssize_t write_with_check(int fd, const void *buf, size_t count) {
    if (pipe_broken) {
        errno = EPIPE;
        return -1;
    }
    
    ssize_t result = write(fd, buf, count);
    
    if (pipe_broken) {
        // SIGPIPE was delivered during write
        errno = EPIPE;
        return -1;
    }
    
    return result;
}

Best Practice: Ignore SIGPIPE

Most production code ignores SIGPIPE and checks for EPIPE after writes. This gives you programmatic control over the error rather than having your process terminate unexpectedly. Set 'signal(SIGPIPE, SIG_IGN)' early in main() for any program using pipes.

Design Patterns for Unidirectional Flow

The unidirectional constraint shapes how we design pipe-based systems. Here are common patterns that work with, rather than against, unidirectional flow:

Pattern 1: Producer-Consumer

The most natural pattern for unidirectional pipes:

[Producer] ─────────▶ [Pipe] ─────────▶ [Consumer]
   write()              buffer            read()

Use when: One process generates data, another processes it. Classic pipeline stages.

Pattern 2: Command-Response (Two Pipes)

Bidirectional communication using two pipes:

[Client]  ═══════▶  [Request Pipe]  ═══════▶  [Server]
           write()       buffer       read()
           
[Client]  ◀═══════  [Response Pipe] ◀═══════  [Server]
           read()        buffer       write()

Use when: Client sends requests, server sends responses. Parent-child worker patterns.

design_patterns.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/wait.h>
 
/**
 * Pattern 3: Fan-Out (One writer, multiple readers)
 * 
 * Tricky with pipes because all readers read from the same buffer.
 * Solution: Each reader gets its own pipe from the producer.
 */
void fan_out_pattern(int num_consumers) {
    int *pipes = malloc(num_consumers * 2 * sizeof(int));
    
    // Create a pipe for each consumer
    for (int i = 0; i < num_consumers; i++) {
        pipe(&pipes[i * 2]);
        
        if (fork() == 0) {
            // Consumer i: read from pipes[i*2]
            close(pipes[i * 2 + 1]);  // Close write end
            
            char buf[256];
            ssize_t n;
            while ((n = read(pipes[i * 2], buf, sizeof(buf))) > 0) {
                buf[n] = '\0';
                printf("[Consumer %d] %s", i, buf);
            }
            
            close(pipes[i * 2]);
            exit(0);
        }
        
        // Producer: keep write end, close read end
        close(pipes[i * 2]);
    }
    
    // Producer distributes data to each consumer
    const char *messages[] = {"Task A", "Task B", "Task C", "Task D"};
    for (int i = 0; i < 4; i++) {
        // Round-robin distribution
        int pipe_write = pipes[(i % num_consumers) * 2 + 1];
        write(pipe_write, messages[i], strlen(messages[i]));
        write(pipe_write, "\n", 1);
    }
    
    // Close all write ends
    for (int i = 0; i < num_consumers; i++) {
        close(pipes[i * 2 + 1]);
    }
    
    // Wait for all consumers
    for (int i = 0; i < num_consumers; i++) {
        wait(NULL);
    }
    
    free(pipes);
}
 
/**
 * Pattern 4: Fan-In (Multiple writers, one reader)
 * 
 * Multiple producers share the same pipe write end.
 * PIPE_BUF atomicity ensures messages don't interleave.
 */
void fan_in_pattern(int num_producers) {
    int pipefd[2];
    pipe(pipefd);
    
    for (int i = 0; i < num_producers; i++) {
        if (fork() == 0) {
            // Producer i: write to pipefd[1]
            close(pipefd[0]);  // Close read end
            
            char msg[64];
            // Keep message small for atomicity
            int len = snprintf(msg, sizeof(msg), 
                              "[Producer %d] Report\n", i);
            
            for (int j = 0; j < 5; j++) {
                write(pipefd[1], msg, len);
                usleep(10000);  // 10ms between writes
            }
            
            close(pipefd[1]);
            exit(0);
        }
    }
    
    // Consumer: read from pipefd[0]
    close(pipefd[1]);  // Close write end
    
    char buffer[256];
    ssize_t n;
    while ((n = read(pipefd[0], buffer, sizeof(buffer) - 1)) > 0) {
        buffer[n] = '\0';
        printf("[Consumer] Received: %s", buffer);
    }
    
    close(pipefd[0]);
    
    // Wait for all producers
    for (int i = 0; i < num_producers; i++) {
        wait(NULL);
    }
}

Pattern 5: Pipeline Chain

The classic shell pipeline, where each stage transforms data:

[Stage 1] ──▶ [Pipe A] ──▶ [Stage 2] ──▶ [Pipe B] ──▶ [Stage 3]
  read()        buf        read() &       buf        read()
                           write()

Use when: Data needs sequential transformations. Each stage focused on one task.

Pattern 6: Control/Data Separation

Use one pipe for data, another for control signals:

           ┌──── Data Pipe ────▶ [High-volume data flow]
[Source] ──┤
           └──── Control Pipe ──▶ [Low-volume commands: PAUSE, RESUME, STOP]

Use when: Need out-of-band signaling alongside data streaming.

Pattern Selection Guide

Choose patterns based on your data flow: Producer-Consumer for simple generation/processing. Two-pipes for request-response. Fan-out for work distribution. Fan-in for aggregation. Pipelines for sequential transformations. Match the pattern to your problem for clean, maintainable code.

Performance Considerations

Understanding the performance characteristics of unidirectional pipes helps you make informed design decisions:

Throughput Factors:

Buffer Size — Larger buffers reduce blocking frequency, increasing throughput for bursty writes. Default 64KB on Linux; tunable via fcntl(F_SETPIPE_SZ).
Copy Overhead — Data is copied twice:
- User space → kernel buffer (write)
- Kernel buffer → user space (read)
For high-throughput scenarios, consider vmsplice() for zero-copy transfer.
Context Switches — Each blocking operation may cause a context switch. Batch data into larger writes to reduce switch frequency.
Lock Contention — The single pipe mutex serializes access. For extremely high concurrency, consider multiple pipes.

Pipe Performance Optimization Strategies
Bottleneck	Symptom	Solution
Frequent blocking	High context switch count	Increase buffer size (fcntl F_SETPIPE_SZ)
Small writes	Low throughput, high syscall count	Batch data into larger write chunks
Copy overhead	High CPU in kernel copying	Use splice/vmsplice for zero-copy
Lock contention	Processes blocking on pipe mutex	Partition work across multiple pipes
Wake-up latency	High latency for small messages	Use eventfd for signaling + shared memory

performance_tuning.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
#define _GNU_SOURCE
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>
 
/**
 * Performance tuning techniques for pipes.
 */
 
// Increase pipe buffer size (Linux-specific)
int set_pipe_size(int fd, int size) {
    int result = fcntl(fd, F_SETPIPE_SZ, size);
    if (result == -1) {
        perror("F_SETPIPE_SZ");
        return -1;
    }
    printf("Pipe buffer set to %d bytes\n", result);
    return result;
}
 
// Check current pipe buffer size
int get_pipe_size(int fd) {
    int size = fcntl(fd, F_GETPIPE_SZ);
    if (size == -1) {
        perror("F_GETPIPE_SZ");
        return -1;
    }
    return size;
}
 
// Efficient large write (handles partial writes)
ssize_t write_all(int fd, const void *buf, size_t count) {
    size_t written = 0;
    const char *ptr = buf;
    
    while (written < count) {
        ssize_t n = write(fd, ptr + written, count - written);
        if (n == -1) {
            if (errno == EINTR) continue;  // Interrupted, retry
            return -1;  // Real error
        }
        written += n;
    }
    
    return written;
}
 
// Batched write for efficiency
#define BATCH_SIZE (32 * 1024)  // 32KB batches
 
typedef struct {
    int fd;
    char buffer[BATCH_SIZE];
    size_t used;
} BatchWriter;
 
void batch_init(BatchWriter *bw, int fd) {
    bw->fd = fd;
    bw->used = 0;
}
 
int batch_write(BatchWriter *bw, const void *data, size_t len) {
    // Flush if this would overflow
    if (bw->used + len > BATCH_SIZE) {
        if (write_all(bw->fd, bw->buffer, bw->used) == -1) {
            return -1;
        }
        bw->used = 0;
    }
    
    // Add to batch
    memcpy(bw->buffer + bw->used, data, len);
    bw->used += len;
    return 0;
}
 
int batch_flush(BatchWriter *bw) {
    if (bw->used > 0) {
        if (write_all(bw->fd, bw->buffer, bw->used) == -1) {
            return -1;
        }
        bw->used = 0;
    }
    return 0;
}

Performance Tip

For maximum throughput, batch small writes into larger ones (32KB+ chunks), increase the pipe buffer size to 256KB-1MB for bursty producers, and consider splice() to move data between pipes and files without user-space copies.

Summary: The Power of One-Way Flow

We've explored unidirectional communication in depth—the defining characteristic that makes pipes simple, efficient, and composable. Let's consolidate the key insights:

Key Takeaways

•Unidirectionality is a feature, not a limitation — It eliminates entire classes of deadlocks, simplifies buffer management, and enables clean pipeline composition.
•Implicit flow control through blocking — Writers block when buffers fill; readers block when buffers empty. This automatic backpressure coordinates producers and consumers without explicit code.
•EOF detection requires closing all write ends — Readers see EOF (read returns 0) only when no write-end file descriptors remain open anywhere.
•SIGPIPE/EPIPE signals the opposite condition — Writers learn when no readers remain through SIGPIPE or the EPIPE error code.
•Non-blocking mode enables event-driven patterns — O_NONBLOCK allows integration with select/poll/epoll for multiplexed I/O.
•Design patterns work with unidirectionality — Producer-consumer, fan-out, fan-in, and pipeline chains all build on the one-way flow model.
•Performance optimization is possible — Buffer sizing, batching, and zero-copy techniques can significantly improve throughput.

What's Next:

With a solid understanding of how data flows through unidirectional pipes, the next page explores the specific patterns for parent-child communication—the primary use case for anonymous pipes, where inheritance provides the only mechanism to share these unnamed channels.

Page Complete

You now deeply understand why pipes are unidirectional, how this design simplifies synchronization and enables composition, and how to work effectively within these constraints. This knowledge prepares you for the parent-child communication patterns in the next section.