You apparently can't share named pipe instances. They short-circuit. When I
open four command shells, do a mkfifo /tmp/fifo, and then do the following:
Shell one and two:
cat /tmp/mkfifo
Shell three and four:
cat > /tmp/mkfifo
Both of the write windows go into the FIRST read window. The second read
window continues to block on the open, getting nothing.
Is this documented somewhere? This wasn't the behavior I expected out of the
suckers. Read blocks until somebody does a write, and write blocks until
somebody does a read, but other writes don't block as long as there's at
least one reader, and the second read blocks until the first goes away. It's
not symmetrical. I can go back to "open /tmp/$pid, read, write, unlink
/tmp/$pid", but it's annoying.
This behavior is posix, perhaps? (2.4.17 kernel if that makes a difference.
It's probably intentional, it's just weird...)
I ran into THIS problem because pipe(3) has an even STRANGER behavior. It
does NOT like being mixed with dup2(). Pesudo-code:
int pipes[2];
pipe(pipes)
dup2(pipes[0],0);
close(pipes[0]);
Boom: the pipe is no longer usable. The stdin instance of it is closed too.
Read from it you get an error. (But if I DON'T close it, I'm leaking file
handles, aren't I? AAAAAAAAH!)
Sigh. It's friday evening. I should go do something else for a while...
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:00:38 EST