select.select() on Regular Files?

[Jim Dennis]

In article <dCuh8.13414$N7.3188706 at ruti.visi.com>, Grant Edwards wrote:
>In article <a65pkr$235o$1 at news.idiom.com>, Jim Dennis wrote:

 ...

> 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.

 O.K. so what can I do for asynchronous I/O notification on 
 regular files?  How can I efficiently block and wake up when
 I/O is available on any of my file descriptors?  

 Don't tell me I have to go into a sleep and poll stat() or
 seek() loop!  It's hard to imagine that UNIX got this far 
 without offering a better solution than that!