ADVERTISEMENT
Responsive Ad Unit • Systems Architecture & Low-Level Engineering

FIFOs (Named Pipes)

A FIFO (First-In First-Out), commonly called a Named Pipe, is a special file that provides byte-stream communication between processes. Unlike anonymous pipes, FIFOs exist in the file system and allow communication between unrelated processes.

Learning Objectives

  • Understand FIFOs.
  • Differentiate FIFOs from anonymous pipes.
  • Learn the mkfifo() system call.
  • Understand FIFO permissions.
  • Study FIFO architecture.
  • Prepare for FIFO programming examples.

1. What is a FIFO?

A FIFO is a special file maintained by the kernel that provides a unidirectional byte-stream communication channel. Processes communicate by opening the FIFO file and performing standard file operations such as read() and write(). Although a FIFO appears as a file in the file system, the data itself is not stored on disk. The kernel transfers the data through an internal buffer.

2. Why are FIFOs Needed?

Requirement Benefit
Communication between unrelated processes No common parent required
Simple IPC Uses normal file operations
Persistent communication endpoint FIFO remains in the file system
Shell scripting Easy integration with commands
Local IPC Efficient kernel-managed buffering

3. Pipe vs FIFO

Feature Anonymous Pipe FIFO
Visible in File System No Yes
Related Processes Usually Required Not Required
Created By pipe() mkfifo()
Pathname No Yes
Communication Style Byte Stream Byte Stream
Kernel Buffer Yes Yes

4. FIFO Architecture

Writer Process ↓ open() ↓ FIFO File ↓ Kernel Buffer ↓ open() ↓ Reader Process

The FIFO pathname provides a rendezvous point for processes. Once opened, data flows through the kernel buffer rather than being stored in the file.

5. mkfifo()

The mkfifo() system call creates a FIFO special file.

#include <sys/stat.h> int mkfifo(const char *pathname, mode_t mode);
Return Value Description
0 FIFO created successfully.
-1 Error occurred.

6. FIFO Permissions

Like regular files, FIFOs use UNIX file permissions to control access.

mkfifo("/tmp/myfifo", 0666);
Permission Meaning
Read Allows reading from the FIFO.
Write Allows writing to the FIFO.
Execute No special meaning for FIFOs.

7. FIFO in the File System

A FIFO appears as a special file in the directory where it is created. The file stores metadata such as ownership and permissions, while the actual communication data remains in kernel memory.

Directory ↓ myfifo ↓ Special File ↓ Kernel FIFO Buffer

8. Creating FIFOs Using the Shell

mkfifo /tmp/myfifo

The mkfifo command creates a named pipe directly from the shell.

9. Advantages of FIFOs

  • Communication between unrelated processes.
  • Simple programming model.
  • Standard file operations.
  • Persistent communication endpoint.
  • Well supported by UNIX systems.

10. Interview Questions

  1. What is a FIFO?
  2. How does a FIFO differ from an anonymous pipe?
  3. Which system call creates a FIFO?
  4. Can unrelated processes communicate using a FIFO?
  5. Where is a FIFO visible?
  6. Does a FIFO store data on disk?
  7. Which header file declares mkfifo()?
  8. Why are FIFOs called named pipes?
  9. How are permissions applied to a FIFO?
  10. What shell command creates a FIFO?

11. Opening a FIFO

Unlike anonymous pipes, a FIFO is opened using the standard open() system call.

#include <fcntl.h> int open(const char *pathname, int flags);

Typical flags include:

Flag Description
O_RDONLY Open for reading.
O_WRONLY Open for writing.
O_RDWR Open for both reading and writing.
O_NONBLOCK Enable non-blocking mode.

12. FIFO Open Behavior

Operation Behavior
Open for Reading Blocks until a writer opens the FIFO (default behavior).
Open for Writing Blocks until a reader opens the FIFO.
Open with O_NONBLOCK Returns immediately according to POSIX rules.
Reader ↓ open() ↓ Wait ↓ Writer Opens FIFO ↓ Communication Begins

13. Reading from a FIFO

After opening the FIFO for reading, the process uses the standard read() system call.

char buffer[128]; ssize_t n; n = read(fd, buffer, sizeof(buffer));

Bytes are read in FIFO order.

14. Writing to a FIFO

A writer transfers data using the standard write() system call.

write(fd, "Hello FIFO", 11);

The kernel delivers the data to any process reading from the FIFO.

15. End-of-File (EOF)

When every writer has closed the FIFO and all buffered data has been consumed, a subsequent read() returns 0, indicating End-of-File.

Writer Closes FIFO ↓ Kernel Buffer Empty ↓ Reader Calls read() ↓ Returns 0 (EOF)

16. FIFO File Descriptors

Once opened, a FIFO is referenced through an ordinary file descriptor, just like a regular file.

Operation System Call
Open open()
Read read()
Write write()
Close close()

17. Example: Reader Process

#include #include #include int main(void) { char buffer[100]; int fd = open("/tmp/myfifo", O_RDONLY); if (fd == -1) return 1; read(fd, buffer, sizeof(buffer)); printf("Received: %s\n", buffer); close(fd); return 0; }

18. Example: Writer Process

#include #include #include int main(void) { int fd; fd = open("/tmp/myfifo", O_WRONLY); if (fd == -1) return 1; write(fd, "Hello FIFO", strlen("Hello FIFO") + 1); close(fd); return 0; }

19. Linux Commands

Command Description
mkfifo /tmp/myfifo Create a FIFO.
ls -l /tmp/myfifo Display FIFO information.
file /tmp/myfifo Identify the file as a FIFO.
rm /tmp/myfifo Remove the FIFO.

20. Interview Questions

  1. Which system call opens a FIFO?
  2. Why is open() used instead of pipe()?
  3. What happens when a reader opens a FIFO before a writer?
  4. When does read() return EOF?
  5. Can multiple processes open the same FIFO?
  6. Why is a FIFO treated like a normal file?
  7. What happens if O_NONBLOCK is used?
  8. Can unrelated processes communicate through a FIFO?
  9. Why does the FIFO pathname remain after communication ends?
  10. Which standard I/O system calls operate on FIFOs?

21. Blocking vs Non-blocking FIFOs

By default, FIFO operations use blocking I/O. A process may wait until another process opens the opposite end of the FIFO or until data becomes available. Non-blocking mode changes this behavior by returning immediately instead of waiting.

Mode Behavior
Blocking Process waits until the operation can proceed.
Non-blocking System call returns immediately if it cannot proceed.

22. Using O_NONBLOCK

Non-blocking mode is enabled when opening the FIFO.

int fd; fd = open("/tmp/myfifo", O_RDONLY | O_NONBLOCK);

Applications using event loops or multiplexed I/O commonly enable non-blocking mode to avoid waiting indefinitely.

23. Multiple Readers and Writers

A FIFO may be opened simultaneously by multiple reader and writer processes. The kernel manages synchronization of the byte stream. However, applications must define their own message boundaries if multiple writers share the same FIFO.

Writer A ↓ Writer B ↓ ==================== Kernel FIFO Buffer ==================== ↓ Reader A ↓ Reader B

24. SIGPIPE

If a process writes to a FIFO after all reader file descriptors have been closed, the kernel generates the SIGPIPE signal. If the signal is ignored or handled, the write() system call fails and returns -1 with errno set to EPIPE.

25. FIFO Kernel Buffer

Like anonymous pipes, FIFOs use a kernel-managed memory buffer for data transfer. The FIFO special file stores only metadata such as permissions and ownership. Communication data remains entirely within kernel memory.

Writer ↓ FIFO File ↓ Kernel Buffer ↓ Reader

26. Complete Communication Flow

Create FIFO ↓ Reader Opens FIFO ↓ Writer Opens FIFO ↓ write() ↓ Kernel Buffer ↓ read() ↓ Close() ↓ Remove FIFO

The FIFO pathname remains in the file system until explicitly removed, even after all communicating processes terminate.

27. Useful Linux Commands

Command Description
stat /tmp/myfifo Display detailed FIFO metadata.
find /tmp -type p Locate FIFO special files.
lsof /tmp/myfifo Show processes currently using the FIFO.
man 7 fifo Display FIFO semantics.

28. Best Practices

  • Create the FIFO before starting communicating processes.
  • Check all return values from mkfifo(), open(), read(), and write().
  • Remove unused FIFOs after communication completes.
  • Handle SIGPIPE appropriately.
  • Use non-blocking mode only when required by the application design.
  • Design application-level message formats when multiple writers share a FIFO.

29. Advanced Interview Questions

  1. What is the difference between blocking and non-blocking FIFO operations?
  2. How is O_NONBLOCK enabled?
  3. Can multiple processes write to the same FIFO simultaneously?
  4. Why must applications define message boundaries when multiple writers exist?
  5. What causes the SIGPIPE signal for a FIFO?
  6. Where is FIFO data actually stored?
  7. Why does the FIFO pathname remain after all processes exit?
  8. How can you determine which processes are using a FIFO?
  9. When would non-blocking FIFOs be preferred?
  10. How does FIFO communication differ from socket communication?

30. FIFO API Summary

Function Purpose
mkfifo() Create a FIFO special file.
open() Open the FIFO.
read() Read bytes from the FIFO.
write() Write bytes to the FIFO.
close() Close the FIFO descriptor.
unlink() Remove the FIFO pathname.

31. FIFO Lifecycle

mkfifo() ↓ FIFO Created ↓ Reader Opens ↓ Writer Opens ↓ Kernel Buffer Created ↓ Data Transfer ↓ close() ↓ unlink() ↓ FIFO Removed

The FIFO pathname remains in the file system until it is explicitly removed using unlink() or the rm command.

32. Pipe vs FIFO vs Socket

Feature Pipe FIFO Socket
Related Processes Usually Yes No No
Visible in File System No Yes UNIX Domain Only
Communication Direction Half-duplex Half-duplex Full-duplex
Uses Pathname No Yes UNIX Domain Only
Network Communication No No Yes
Kernel Buffer Yes Yes Yes

33. Common Programming Mistakes

  • Creating a FIFO that already exists.
  • Ignoring errors returned by mkfifo().
  • Forgetting to remove unused FIFOs.
  • Assuming FIFO data is stored on disk.
  • Ignoring blocking behavior.
  • Not handling SIGPIPE.
  • Using one FIFO when independent bidirectional communication is required.

34. Debugging Tips

Problem Possible Cause
open() blocks forever Opposite endpoint not opened.
write() fails No active readers.
FIFO already exists Previous FIFO not removed.
No data received Writer closed unexpectedly.
Application hangs Blocking I/O waiting for peer.

35. Best Practices

  • Create the FIFO during application initialization.
  • Choose appropriate file permissions.
  • Remove temporary FIFOs when no longer needed.
  • Validate every system call.
  • Use application-level message formats for structured communication.
  • Document FIFO locations for maintenance.
  • Use sockets instead of FIFOs when communication must span multiple machines.

36. Advanced Interview Questions

  1. Explain the complete lifecycle of a FIFO.
  2. Why is a FIFO called a named pipe?
  3. What happens if a FIFO already exists when mkfifo() is called?
  4. When should a FIFO be removed?
  5. How is a FIFO different from a UNIX domain socket?
  6. Can multiple readers open the same FIFO?
  7. How does the kernel buffer FIFO data?
  8. What is the role of unlink()?
  9. When would sockets be preferred over FIFOs?
  10. What debugging tools are useful for FIFO communication?

37. Module Summary

In this module, we studied FIFOs (named pipes), which extend anonymous pipes by providing a pathname in the file system. We learned how to create FIFOs using mkfifo(), access them with open(), communicate using read() and write(), understand blocking behavior, kernel buffering, non-blocking mode, SIGPIPE, debugging techniques, and recommended programming practices. FIFOs are suitable for local communication between unrelated processes. The next module introduces the System V IPC facilities, which provide message queues, semaphores, and shared memory for more advanced inter-process communication.

Next Module

The FIFOs (Named Pipes) module is now complete. Continue to: XSI IPC (System V IPC)

Next → XSI IPC
Knowledge Check

Concept Mastery Assessment — Module 41

Verify your conceptual understanding with 12 targeted technical assessment questions. Instant feedback and explanations are provided for every choice.

Question 1 of 12
What is the primary architectural purpose of Named Pipes (FIFOs) in operating systems?
Explanation
Named Pipes (FIFOs) is designed to manage mkfifo system call, filesystem entry binding, bidirectional rendezvous semantics, o_nonblock open dynamics, and client-server fifos. within the operating system architecture.
Question 2 of 12
Which system interface or data structure is centrally associated with Named Pipes (FIFOs)?
Explanation
Under POSIX and Linux, Named Pipes (FIFOs) operates through standardized system calls and kernel control structures.
Question 3 of 12
What safety or concurrency constraint must developers consider when implementing Named Pipes (FIFOs)?
Explanation
Proper synchronization, avoidance of race conditions, and handling reentrant execution are critical when working with Named Pipes (FIFOs).
Question 4 of 12
When a system call related to Named Pipes (FIFOs) fails in C, how does the POSIX runtime conventionally report the failure?
Explanation
Standard POSIX system calls return -1 or NULL on error, assigning an error integer (e.g. EINVAL, EPERM, EAGAIN) to the thread-local errno variable.
Question 5 of 12
What is the primary performance tradeoff associated with Named Pipes (FIFOs)?
Explanation
Operations involving Named Pipes (FIFOs) balance performance against kernel transition, memory bandwidth, and cache locality tradeoffs.
Question 6 of 12
What security principle governs access to resources in Named Pipes (FIFOs)?
Explanation
The kernel validates credentials, effective permissions, and Linux capabilities before granting access to protected operations.
Question 7 of 12
How does execution of Named Pipes (FIFOs) transition between User Space and Kernel Space?
Explanation
User space transitions to kernel mode securely via software traps or SYSCALL instructions that switch processor rings to Ring 0.
Question 8 of 12
What happens to resources allocated by Named Pipes (FIFOs) when the owning process terminates?
Explanation
Process resources (open fds, memory maps) are automatically reclaimed by the kernel on termination, while kernel-persistent objects survive.
Question 9 of 12
In production Linux server environments, how is Named Pipes (FIFOs) optimized for high throughput?
Explanation
Linux optimizes throughput via zero-copy data paths, asynchronous kernel events, and scalable concurrency primitives.
Question 10 of 12
What standard governs the portability of Named Pipes (FIFOs) across Unix, Linux, and macOS platforms?
Explanation
IEEE POSIX standards define consistent APIs across Unix-like platforms ensuring portable source code execution.
Question 11 of 12
Which command-line diagnostic tool is most effective for inspecting and troubleshooting Named Pipes (FIFOs) at runtime?
Explanation
Utilities like strace, lsof, and the /proc filesystem provide direct visibility into kernel interactions and resource status.
Question 12 of 12
What is a critical production best practice when developing systems software involving Named Pipes (FIFOs)?
Explanation
Defensive programming requires explicit error checking on all system operations, proper resource cleanup, and avoiding memory corruption.
0 / 12 (0%)
Great job! Review the concepts above and proceed when ready.
ADVERTISEMENT
Responsive Ad Unit • Technical Courses & Certifications