On Jan 30, 2007, at 6:17 PM, Eric Hodel wrote:
> If there are other threads and the IO isn't readable, ruby will run  
> those until they complete.  Your thread immediately stopped.

I coded it that way on purpose to see if the issue depended on  
whether another thread was running.  On my platform it doesn't  
matter.  It also doesn't matter if the main thread joins the now dead  
thread.  It is the initiation of
another thread that changes the behavior of IO#eof? on certain  
platforms.  The two platforms that have been reported
are:
	ruby 1.8.5 Linux 2.6.17-2-686 i686
	ruby 1.8.5 Darwin 8.8.0 Power Macintosh  (Mac OS X 10.4.8)

> 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.

But my point (and James' point) was that on my (his) platform it  
*doesn't* block when it logically should.

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

I did that and came up with the simpler example in the process.  If  
you run just:

   p $stdin.eof?

Ruby blocks waiting for input.  If you first create a thread
which immediately terminates (my simple example) then Ruby doesn't
block (ruby 1.8.4 on Mac OS X) instead the read call is interrupted
with a software interrupt, which I interpreted as being party of Ruby's
thread implementation.

Gary Wright