From: Jeff Putsch <putsch@...>
Date: 2002-08-22T07:02:29+09:00
Subject: Re: select on solaris

On Thu, Aug 22, 2002 at 06:45:19AM +0900, Berger, Daniel wrote:
> Hmm..ok.  Without any testing on my own whatsoever, would testing against
> empty? instead of nil? be a viable workaround?

Nope. Here's a simple test case:

  #!/usr/sepp/bin/ruby

  def run_command
    f = IO.popen("cat /etc/hosts") 
  
    while not (r=select([f])).empty?
      p r
      p r[0][0].gets.to_s
    end
  
  end
  
  run_command

And here's the output:

  [[#<IO:0x4a848>], [], []]
  "#\n"
  [[#<IO:0x4a848>], [], []]
  "# Internet host table\n"
  [[#<IO:0x4a848>], [], []]
  "#\n"
  [[#<IO:0x4a848>], [], []]
  "127.0.0.1\tlocalhost \n"
  [[#<IO:0x4a848>], [], []]
  "172.17.100.124\tblue.mxim.com blue\n"
  [[#<IO:0x4a848>], [], []]
  "\tparis.mxim.com           loghost\n"
  [[#<IO:0x4a848>], [], []]
  "172.17.100.5\tparis.mxim.com          loghost\n"
  [[#<IO:0x4a848>], [], []]
  ""
  [[#<IO:0x4a848>], [], []]
  ""
  [[#<IO:0x4a848>], [], []]
  ""
  [[#<IO:0x4a848>], [], []]

As you can see, once the lines in the file are exhausted, #select still 
returns (it should block forever at that point) and it claims the
IO object has data ready to be read on it (it doesn't). If I check for 
f.eof? in the while loop, I can detect the end of the data.

Checking with #eof? when using Open3.popen3 is a bit trickier because
it is conceivable to me that I'd get an eof on stdout, but not stderr. Still
doable.

I can check in the while loop to see if I actuall read data. This really isn't
a good solution.

I still think there is something wrong with the behavior of #select. It should
not return until there is data ready. Picture an IO.popen() call to 
a long running process that periodically spits data, but only at 30
second intervals. The current behavior of #select will cause the loop
to run quite a lot of iterations doing nothing but noticing there
really wasn't any data (your basic busy wait).

That's why I think #select is broken, or I'm not using it right.

> I should get a chance to play with this more tomorrow.

Any help/insight is greatly appreciated. Thanks.

Jeff.
-- 
Jeff Putsch                       Email: putsch@mxim.com
Maxim Integrated Products        Office: (503)547-2037
High Frequency CAD Engineering