Question

Background
I’m playing around with a FIFO and every time I try to write on my fifo it blocks until someone is reading the other side of the fd:

int fd;
char buffer[100] = {0};
char * myfifo = "/tmp/myfifo";    

mkfifo(myfifo, 0666);
printf("What would you like to send?\n");
fgets(buffer, 100, stdin);

if((fd = open(myfifo, O_WRONLY)) < 0)
    printf("Couldn't open the FIFO for writing!\n");
else {
    write(fd, buffer, strlen(buffer));
    close(fd);

This code works, but it blocks until I read the /tmp/myfifo side and get the data. When I change the code as such:

if((fd = open(myfifo, O_WRONLY | O_NONBLOCK)) < 0)

Then the open fails with error No such device or address, unless I have someone sitting blocked on the “read” side.

Analysis
As per the man page for fifo():
The kernel maintains exactly one pipe object for each FIFO special file that is opened by at least one process. The FIFO must be opened on both ends (reading and writing) before data can be passed. Normally, opening the FIFO blocks until the other end is opened also.

So this is expected operation.

Question

Based on my experiments, and what I’m reading… I have to assume a FIFO is a non-queued, non-buffered mechanism and only works when there is a process sitting and waiting for data.

Is there a different communication mechanism that works in a non-blocked buffered manor, basically a buffered FIFO, or would I have to make my own message storage/notification system for that?

EDIT

I say I’m “playing around” which is actually pretty descriptive here. I’m trying to learn the ins and outs of the various IPC mechanisms (FIFOs, sockets, and pipes). I’m working towards learning to use select() and understand what can be used to wake up sleeping processes which call select. Reason being it’s part of a communications driver I’m analyzing for port to a new platform.
I excluded this from the original post as it is sort of irrelevant. I’m just trying to make sure I can understand (at the moment) FIFO’s, how to use them, the limitations on them, and other IPC mechanism. Hence my original assumption/questions about “better” versions of FIFO that will store data and can be written to without blocking.

Answer 1

Not only is a FIFO buffered, but that’s basically all a FIFO is. A FIFO is little more than a buffer in the kernel.

Discussion: The kernel has a policy that it refuses to write data to the buffer unless a process has the FIFO open for reading. This behavior is similar to pipes and TCP connections, although if there’s no reader for a pipe or a TCP connection, the kernel will actually signal the writing process, terminating it (unless you install a handler). This behavior allows us to string together commands the way we expect, e.g.,

hexdump file.dat | head

The hexdump program gets killed once head reads a few lines. This is what we want 99% of the time, and hexdump doesn’t need any special code to achieve this.

Solutions: It would help if you describe some more context about the problem you are trying to solve.

1. If you want a client/server system where the server queues messages that can be read by the clients, you can achieve this with Unix domain sockets. Unix domain sockets are similar to FIFOs but more flexible in various ways. (Most database servers prefer Unix domain sockets over other types of IPC.)

2. If you want to be able to store a persistent queue, where applications can independently enqueue and dequeue messages, then you will need to use ordinary files.

Unfortunately, “playing around with a FIFO” is not much to go on. If you want a good exercise in IPC, try writing a chat server that uses Unix domain sockets or TCP (or both at the same time, which isn’t much harder). You can use telnet or nc (netcat) as a client. (Make sure you have the “OpenBSD” version of netcat.)