Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!tellab5!chinet!les From: les@chinet.chi.il.us (Leslie Mikesell) Newsgroups: comp.unix.programmer Subject: Re: Using select on FIFO's Message-ID: <1991May30.165554.4079@chinet.chi.il.us> Date: 30 May 91 16:55:54 GMT References: Distribution: comp Organization: Chinet - Chicago Public Access UNIX Lines: 41 In article Bjorn.Larsen@usit.uio.no writes: >Yesterday, I wanted to use select(2) to wait on a number of FIFO's >that were opened for reading. It turned out to be harder than I >expected. [...] >So I came up with the following 'solution': > > int fd, wfd; > >/* Open the FIFO for nonblocking read */ > fd = open("/tmp/FIFO", O_RDONLY|O_NONBLOCK); > >/* Open the FIFO for write (won't hang, since it is open for read) */ > wfd = open("/tmp/FIFO", O_WRONLY); > >/* Close the read descriptor */ > close(fd); > >/* Open the FIFO for blocking read */ > fd = open("/tmp/FIFO", O_RDONLY); > >After these acrobatics, the file descriptor 'fd' can be used with >select(). I don't have select(), but I've always just opened the FIFO with O_RDWR on the reader side which (a) doesn't block during the open, and (b) does cause the read()s to continue to block for data instead of returning EOF after a writer has closed. This allows the writers to come and go as necessary. If you can arrange for every action the daemon is supposed to perform to be triggered by a write to the FIFO, you can just let the read block. Of course if you want to see EOF when the writer exits, you can't do it this way. I would expect select() to wake up when the last writer closes, so you would control seeing this by whether or not the reading process also opens for writing. However, if the reading process does not open for writing, after the FIFO has been opened and closed by a writer it will return EOF immediately instead of blocking whenever no writer has it open. Select() shouldn't block in this case either. Les Mikesell les@chinet.chi.il.us