On 27.06.2009 16:43, Mat Brown wrote: > On Sat, Jun 27, 2009 at 02:37, David Miller <dmiller / tecolote.net> wrote: >> 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. >> 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}" > 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. Normally I would expect "ready for reading" to mean that it is open *and* there is some data that can be read. Otherwise it does not really make sense to include such an fd in the set returned. http://www.manpagez.com/man/2/select/ Having said that I do have experienced "ready for reading" returns if the other party of a TCP socket connection has closed the socket already resulting in a 0 byte non blocking read operation. But that seems to be mostly related to the peculiarities of networks work. So, under normal conditions select should block until data is actually readable (when using with a non empty set of descriptors you want to examine for readability, of course). David's expectations are absolutely in line with what I would expect and as it turns out this seems to be a problem of a particular version only. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/