Polling, Fifos, and Linux

[Donn Cave]

In article <mailman.1511.1120829376.10512.python-list at python.org>,
 Andreas Kostyrka <andreas at kostyrka.org> wrote:
> On Thu, Jul 07, 2005 at 10:21:19PM -0700, Jacob Page wrote:
> > Jeremy Moles wrote:
> > > This is my first time working with some of the more lower-level python
> > > "stuff." I was wondering if someone could tell me what I'm doing wrong
> > > with my simple test here?
> > > 
> > > Basically, what I need is an easy way for application in userspace to
> > > simply echo values "down" to this fifo similar to the way proc files are
> > > used. Is my understanding of fifo's and their capabilities just totally
> > > off base?
> > 
> > You shouldn't need to use select.poll(), unless I'm missing something. 
> > I was able to get the following to work:

> Ok, you miss something ;) The program you proposed does busy waiting
> and without a time.sleep call will consume 100% CPU time :(

I don't doubt that it would, but that's because he (like the
original poster) open the file with O_NONBLOCK.  From my point
of view that's a self-inflicted injury, but if you start from
the assumption that O_NONBLOCK is needed for some reason, then
the poll makes sense.  In normal blocking mode, select+read is
identical to plain read for any kind of file that supports select.

> Actually, with a named fifo the situation gets even nastier:
> 
> import os, select, time
> 
> fifo = os.open("fifo", os.O_RDONLY)
> 
> while True:
>     print "SELECT", select.select([fifo],[],[])
>     string = os.read(fifo, 1)
>     if len(string):
>         print string
>     else:
>         nf = os.open("fifo", os.O_RDONLY)
>         os.close(fifo)
>         fifo = nf
>     # Perhaps add a delay under an else
> 
> The problem is, that select (and poll) show a End-Of-File condition by 
> returning
> ready to read. But on a FIFO, when the first client terminates, the reading
> end goes into a EOF state till somebody else reopens the fifo for writing.
> 
> [This bit of wisdom comes Advanced Programming in the UNIX Environment by 
> W.R. Stevens p. 400: 'If we encounter the end of file on a descriptor, that
> descriptor is considered readbale by select.']
> 
> closing the old descriptor must be done after opening a new one, or else you
> get a tiny moment where a O_WRONLY client is not able to open the file.
> This way there is always a reading client of the fifo.

OK, but in more detail, what happens in these two scenarios?
In your version, what happens when the writer opens a pipe
pipe that the reader is about to close?  Who reads the data?

On the other hand, if you close the pipe first, what happens
to the writer who happens to try to open the pipe at that moment?

Luckily, as far as I know, we don't have to worry about the
first one, since if data could be lost in this way it would
be much more complicated to close a file descriptor without
running this risk.

But I don't see the second one as much of a problem either.
The writer blocks - so?

Now, what would really be useful is a way for the writer to
detect whether open will block, and potentially time out.

   Donn Cave, donn at u.washington.edu