select.select() on Regular Files?

[Grant Edwards]

In article <a65pkr$235o$1 at news.idiom.com>, Jim Dennis wrote:

>  I'm trying to figure how to write a daemon that will
>  efficiently wait for activity on any of several file and/or
>  socket descriptors.

[...]

>  Unfortunately it continually outputs.  I don't understand why
>  if there's no more data at the end of the file.  Is my read()
>  not pushing my file position all the way to the EOF?  It's as
>  though there's *always* data available on that file descriptor.

You've misunderstood what select() is telling you.  When select
returns a read fd, that doesn't mean there's data available. It
means that a read() call on that fd will not block.  A read()
call on a regular file's fd never blocks: it always returns
immediately with data or with EOF.  Therefore, select() will
always return a read fd immediately for a regular file.

IOW, select() is supported for regular files, but the semantics
aren't very useful.

>  This seems to contradict the documentation:
> 
> Wait until one or more file descriptors are ready for some kind
> of I/O.

"ready for some kind of I/O" means that the read() or write()
call will not block.  In the case of a read fd it doesn't imply
that there is data available.

>  Is this a bug?  I'm using Python2.2 as packaged by Debian (unstable)
>  on a Debian GNU/Linux system  (what a surprise, a Debian package 
>  on a Debian system!) under 2.4.9 SMP kernel).

Probably -- in the sense that the documenation was not
sufficient to prevent a surprise.  Not in the sense that the
select() call doesn't do what the designers intended.

>  Would poll() be a better choice?  The __doc__ for that is a bit
>  terse.

IIRC, poll() will do the same thing.

-- 
Grant Edwards                   grante             Yow!  Is this "BOOZE"?
                                  at               
                               visi.com