From: ara.t.howard@...
Date: 2007-01-31T07:35:12+09:00
Subject: Re: Net::HTTP Closes STDIN

On Wed, 31 Jan 2007 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.  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
>

sounds quite reasonable.  however, on my box:

   harp:~ > cat a.rb
   Thread.new { }
   p $stdin.eof?

   harp:~ > ruby a.rb  # and then type ctrl-d
   true

   harp:~ > ruby -v
   ruby 1.8.4 (2005-12-01) [i686-linux]

   harp:~ > uname -srm
   Linux 2.4.21-47.0.1.EL i686

so looks to be a bsd/mac issue?

-a
-- 
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama