Title: Why does writing to a named pipe continue after no one is reading?
Tags: c;unix;named-pipes
Question: I'm doing some experiments to learn about named pipes. It's my understanding that the OS will block a program that writes to a named pipe until another program reads from the named pipe. So I've written two programs, ```startloop``` and ```readbyte```. ```startloop``` creates a fifo and continually writes to it with each read of the client (```readbyte```):

```#include <stdio.h&gt;
#include <stdlib.h&gt;
#include <fcntl.h&gt;
#include <unistd.h&gt;
#include <sys/stat.h&gt;

int main(int argc, char *argv[]) {
    const char num = 123;
    mkfifo("fifo", S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP);
    int fd = open("fifo", O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
    while (1) {
        printf("loop_start\n");
        write(fd, &amp;num, sizeof(num));
    }
    close(fd);
    return 0;
}
```

```readbyte``` reads one byte from the fifo when run:

```#include <stdio.h&gt;
#include <unistd.h&gt;
#include <stdlib.h&gt;
#include <fcntl.h&gt;

int main(int argc, char *argv[]) {
    char num;
    int fd;
    if ((fd = open(argv[1], O_RDONLY, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH)) == -1) {
        perror("Cannot open input file\n"); exit(1);
    }

    read(fd, &amp;num, sizeof(num));
    printf("%d\n", num);
    close(fd);
    return 0;
}
```

```readbyte``` prints the number as expected when run on "fifo":

```hostname:dir username$ ./readbyte fifo 
65
```

As I expect, ```loopstart``` doesn't print anything until I read from the fifo with ```readbyte```. However, when it becomes unblocked, it writes to "fifo" several times instead of immediately being suspended. Why is this?

```hostname:dir username$ ./startloop
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
loop_start
```

Comment: @Andrew Henle-I know it at least succeeds in some fashion because `readbyte` prints what was written. I did have a version with error checking--I removed all that to make the post shorter, though. I can add it back in if you think that's the problem.

Comment: I agree that adding that information would be a good idea. In this case, it can actually hide the problem. When I add a loop counter, I get a single line of output, `loop 0, wrote 1 bytes`. Sometimes when I run I'll get two lines. The time that the `printf` takes with the extra arguments ends up hiding the number of loops performed.

Comment: How do you know the `write()` call succeeds?  You're not checking its return value.

Comment: The fact that your loop continues just means `write()` didn't *block*, not that is *succeeded*.  There's a huge difference.  If you don't know what's happening and want help, the more data you post the better the help you'll get.  In this case, emitting a loop counter along with the return value from `write()` would have been a lot better than a simple "loop_start".  This was an easy problem to solve - solving much harder problems will *need* that extra information.

Here is the accepted answer: "It's my understanding that the OS will block a program that writes to a named pipe until another program reads from the named pipe."

That understanding is incorrect. ```write``` will not block unless the pipe/fifo is full. From the pipe manul:

```
  A pipe has a limited capacity. If the pipe is full, then a write(2)
  will block or fail, depending on whether the O_NONBLOCK flag is set
  (see below).
```

As to why the first ```write``` appears to block - it actually doesn't. It is the ```open``` that blocks. From the fifo manaul:

```
  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.
```

Update: Actually the above is true for the first ```write```. But there is probably more to explanation. Once the ```readbyte``` program closes the fifo, subsequent ```write``` calls should start failing.

Comment for this answer: @rici Thanks and agreed, that is a valuable clarification.
Comment for this answer: Once the reader closes the fifo, the write call will fail with `EPIPE` but only if `SIGPIPE` is being ignored. Since the signal is not ignored by default and the default action is to terminate the process, you can expect several writes to succeed, until the pipe is closed, and then the process to die.

Here is another answer: test the write result

``` while (1) {
        printf("loop_start\n");
     int ret =  write(fd, &amp;num, sizeof(num));
     if(ret == -1)
     {
        perror("error writing to fifo");
        exit(1);
     }
    }
```


{'source': 'StackExchangeDataset', 'subset': 'stackoverflow.com', 'metadata': {'AnswerCount': 2, 'CommentCount': 4, 'ContentLicense': 'CC BY-SA 3.0', 'CreationDate': '2016:00:01/05/16', 'FavoriteCount': None, 'PostTypeId': 1, 'Tags': '<c><unix><named-pipes>', 'Title': 'Why does writing to a named pipe continue after no one is reading?', 'ViewCount': 2773, 'id': 34621757, 'user_AboutMe': '', 'user_AccountId': 1102604.0, 'user_DisplayName': 'watkipet', 'user_Reputation': 887.0, 'user_Views': 92.0, 'user_id': 1094670.0}}