It doesn't that's why no one does it.

But for pipes what it means is that if whoever is reading or writing the pipe expects non blocking semantics, the other end needs to agree. And if they don't you'll eventually get an error because the reader or writer outpaced the other, and almost no program handles errors for stdin or stdout.

Making the read side non-blocking doesn't affect the write side, and vice-versa.

That is not true for pipes.

It is, at least on Linux for ordinary pipe(2) pipes.

I just wrote up a test to be sure: in the process with the read side, set it to non-blocking with fcntl(p, F_SETFL, O_NONBLOCK) then go to sleep for a long period. Dump a bunch of data into the writing side with the other process: the write() call blocks once the pipe is full as you would expect.

But even writing to a file doesn't guarantee non-blocking semantics. I still don't get what is special about pipes.