I have been experimenting with IO::Reactor to implement a multi-file
"tail -f". It works, but the `select' call that is made within
IO::Reactor returns immediately with a ":read" indication whether there
is new data to read at the end of the file or not [this is with
`poll(-1)']. Therefore, I can get my "tail -f" logic to work, but only
at the expense of lots of useless looping.
Is there something I can do to make the `select' call block at end
of file until new data appears, or is the behavior I'm seeing intrinsic
to `select' on a Unix system? I'm using FreeBSD, if that makes any
difference.
I have already successfully implemented a multi-file "tail -f" in ruby
using a different approach, and so I'm not looking for a solution to
that particular problem. I'm just experimenting with IO::Reactor and
I'm curious about this property of `select'.
Thanks in advance for any light that any of you can shed on this.
···
--
Lloyd Zusman
ljz@asfast.com
God bless you.
Never mind ... I figured out the answer to my question. See below:
Lloyd Zusman <ljz@asfast.com> writes:
[ ... ]
Is there something I can do to make the `select' call block at end
of file until new data appears, or is the behavior I'm seeing intrinsic
to `select' on a Unix system? I'm using FreeBSD, if that makes any
difference.
The `select' manpage on my FreeBSD system says nothing about EOF, but I
looked at a Linux manpage for that function, and it states that `select'
will consider a file descriptor to be `ready' for reading even if it's
in the EOF state. That explains the behavior I'm seeing.
Sorry for the bandwidth.
···
--
Lloyd Zusman
ljz@asfast.com
God bless you.
Lloyd Zusman <ljz@asfast.com> writes:
to `select' on a Unix system? I'm using FreeBSD, if that makes any
select() is not particularly useful in dealing with disk i/o. It
always indicates readiness for any disk i/o. AFAIK, most unix-like
OSes share this behaviour. I seem to remember that only some unix-like
OSes in 1970-1980 that do not.
YS.