On Jan 30, 2007, at 13:31, gwtmp01 / mac.com wrote:
> 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.

If there are other threads and the IO isn't readable, ruby will run  
those until they complete.  Your thread immediately stopped.

Since the thread in your example has completed there's no threads to  
switch to, so the main thread blocks waiting for a character (on a  
BSD-ish libc).  If there was a thread running, the main thread would  
remain blocked (as if it were blocked on getc(3)) and the other  
threads were running.

To figure out what your platform is doing use a tool that gives  
system-call information like ktrace.