>> 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 [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
