Two completely unrelated processes — a log producer and a log consumer started independently — need to stream data between them. Which statement is correct?
AAn unnamed pipe works; the kernel automatically connects processes that want to communicate
BA named pipe (FIFO) works; an unnamed pipe would not, because unnamed pipes require file descriptors shared through fork()
CNeither works; only sockets support communication between unrelated processes
DBoth work as long as both processes run as the same user
Unnamed pipes are created by pipe() and their file descriptors live only in the process that called pipe(). The only way to share them is through fork() — so only parent-child or sibling processes can use them. A named pipe (FIFO) solves this by creating a filesystem path via mkfifo; any process with access to that path can open it independently, with no shared ancestry required. The kernel still buffers data in memory — no disk I/O occurs.
Question 2 Multiple Choice
A process writes 'hello' and then 'world' to a pipe in two separate write() calls. What can the reader reliably expect?
AExactly two reads: first 'hello', then 'world' — pipes preserve write boundaries
BAny byte split: 'helloworld' in one read, 'hel'+'loworld', or other arbitrary divisions — pipes are byte streams
COnly the second write survives — 'world' — because pipes work like a single-slot queue
DThe reader blocks indefinitely because pipes don't support back-to-back writes
Pipes transfer raw byte streams with no message framing. The kernel buffers all bytes in order, but the reader's read() calls have no obligation to align with the writer's write() calls. A single read() might return all 10 bytes at once, or the data might arrive in arbitrary splits depending on timing and buffer state. If message boundaries matter, use a higher-level IPC mechanism — message queues or sockets — that preserves framing.
Question 3 True / False
Data written to a named pipe (FIFO) travels through a kernel memory buffer and is never written to disk, even though the FIFO appears as a file in the filesystem.
TTrue
FFalse
Answer: True
The filesystem entry for a named pipe is purely a rendezvous point — a name that unrelated processes can open. The actual data flows through a kernel memory buffer, identical to how unnamed pipes work. This makes named pipes fast (no disk I/O) but non-persistent: data exists only while processes hold the pipe open. If all processes close the FIFO, any unread data in the buffer is discarded.
Question 4 True / False
When a writer process finishes and closes its end of a pipe, the reader receives an error code indicating failure on its next read() call.
TTrue
FFalse
Answer: False
When all write ends of a pipe are closed, the reader's read() returns 0 — the standard Unix end-of-file signal — not an error. This is intentional: it allows pipelines to compose cleanly. The reader distinguishes 'no data available yet, block and wait' (write end still open, buffer empty) from 'writing is done, nothing more will come' (write end closed, returns 0). Errors (negative return values) indicate actual I/O failures, not normal completion.
Question 5 Short Answer
Explain why an unnamed pipe cannot be used between two unrelated processes, and what mechanism named pipes use to solve this problem.
Think about your answer, then reveal below.
Model answer: Unnamed pipes exist only as file descriptors in the creating process's memory — there is no filesystem name an unrelated process can discover. The file descriptors can only be shared by inheriting them through fork(), limiting unnamed pipes to related (parent-child or sibling) processes. Named pipes solve this by registering a filesystem path via mkfifo; any process that can access that path can open the pipe by name, providing a rendezvous independent of process ancestry.
The filesystem namespace is the key: it's a shared naming system that any process can consult, regardless of heritage. Just as two unrelated programs can both open /tmp/foo.txt, they can both open /tmp/myfifo. The kernel then connects their reads and writes through the same in-memory buffer mechanism as unnamed pipes. The filesystem entry is just a door — the actual communication channel is always in-memory, never on disk.