On Jan 27, 2007, at 8:13 PM, James Edward Gray II wrote:

> Kenneth Kalmer has brought up a HighLine issue and I'm trying to  
> look into it.  Oddly, it seems to happen when interacting with the  
> Net::HTTP library.  I've narrowed it done to the following example  
> on my box:

Here is a simpler example that illustrates the issue:

   Thread.new { }
   p $stdin.eof?

As Eric Hodel pointed out, EOF on a terminal device is detected by  
trying to read from
the device.  It appears that *prior* to the creation of a thread, a  
read on a terminal
device will simply block waiting for some activity on the device;  
either actual data
or indication of an eof condition (someone typing control-d).

*After* a thread has been created, Ruby's green thread implementation  
kicks in.  This
means that the read caused by IO#eof? on the terminal device is not  
allowed to block.
Instead it fails as an interrupted system call, which is interpreted  
by IO#eof? as an
end of file condition.  This is true even if the main thread is the  
only running thread.

James' original example used Net::HTTP, which uses Timeout, which  
creates a thread to
gain control of code that may block (i.e., an HTTP connection to a  
remote host).

I don't know enough about Ruby's thread implementation to know if  
this is a bug or
a feature.  My hunch is that IO#eof? needs to be fixed so that an  
interrupted system
call doesn't get interpreted as an end of file condition.  Another  
change would be to
turn off the software interrupt that is used to multiplex IO activity  
by threads when
only the main thread is running.

Gary Wright