On Sat, Jun 27, 2009 at 02:37, David Miller <dmiller / tecolote.net> wrote:
>
> Hello all
>
> I was looking at some code in a textmate bundle support library that
> wasn't working for me. (I am using e text editor on a XP machine) The
> problem appears to be that IO.select is returning a value that I believe
> means that data is available to be read, however there does not seem to
> be any data available. I have read what I can find about this, but I
> don't understand the result I am seeing.
>
> If I run demo code below, IO.select returns immediately. data[0]
> contains $stdin, but there are no characters in the stdin buffer so the
> getc blocks waiting for input. If I enter several characters and hit
> return, the first two characters will show up in the two data[0].getc
> statements.
>
> In this example I thought the IO.select would wait for up to 20 seconds
> for characters to be available, and return a nil at that time if none
> were.
>
> This is a XP box running 1.8.6
>
> What am I missing?
>
> Thanks
>
> Dave M
>
>
>
>
> data, x, x = IO.select([$stdin], nil, nil, 20.0)
>
> puts "$stdin.to_s returns: #{$stdin.to_s}"
> puts "$data[0].to_s returns: #{data[0].to_s}"
>
> puts "data[0].getc.to_s returns: #{data[0].getc.chr}"
> puts "data[0].getc.to_s returns: #{data[0].getc.chr}"
> --
> Posted via http://www.ruby-forum.com/.
>
Dave,
My experience with IO.select is that if you select on an input stream,
it blocks until the stream is opened for writing by another process,
not until there is actual data to be read. Presumably $stdin is always
going to be open for writing, so IO.select will return immediately. If
you try this on a *nix box, at least, using a FIFO you should see the
same behavior. Unfortunately, IO#select appears to be undocumented in
the Ruby core, but presumably it just passes the call through to the C
function; here's what the linux man pages have to say about the input
argument:
If the readfds argument is not a null pointer, it points to an object
of type fd_set that on input specifies the file descriptors to be
checked for being ready to read, and on output indicates which file
descriptors are ready to read.
Of course, "ready to be read" here is a bit ambiguous, but as I said,
experience suggests that it refers to having been opened for writing,
rather than not having an EOF condition.
Hope that helps,
Mat