Re: FIFO blocking behaviour

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Is it safe to have process A create the FIFO, pass the name to
>> process B, open it for writing (write to it), and then "immediately"
>> delete it?  Is it then guaranteed that process B will be able to
>> open the FIFO (and, of course, read from it)?

Only if you somehow ensure that B opens it before A unlinks it.  The
FIFO will be inaccessible if no filesystem names refer to it any longer
(though in some circumstances it may still exist in some senses).

Or, if B unlinks it, you need to ensure A opens it before B unlinks it.
More generally, each process needs to have it open before it gets
unlinked.

> B waits for A to send it the name of the FIFO it'll create,
> A creates the FIFO and passes name to B,
> B opens FIFO for reading.
> A deletes FIFO & waits an arbitrary amt. of time before writing,
> then B will read what A wrote (subject to PIPE_BUF limits) even if
> the FIFO is gone.

Only if A opens it as well before deleting it.  Creating a filesystem
FIFO is a mknod() call; unlike a file, creating one does not include
opening a file descriptor onto it.  (Arguably an open() call with
S_FIFO set in the mode argument should do that, but that'd be a
significant deviation from historical practice and for all I know might
be forbidden by some standard or other.)

But I would say the FIFO is not gone in this case; only the filesystem
name referring to it is gone.  In that respect it is in much the same
state as a file that has been unlinked but is still open.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B