On 05.01.2010 13:07, Brian Candler wrote:
> Robert Klemme wrote:
>>> It creates the thread properly, but when the sleep expires and it is
>>> ready to call stdin.puts(), it cannot do anything, because the loop
>>> continued around and it is reading from stderr.
>>
>> That can't normally be, because the thread runs independently of the
>> loop.
>
> He's right, and I have replicated the problem. It occurs with with 1.8.6
> one-click installer under Windows. With this interpreter, threads are
> borked: when one thread is waiting on I/O, it prevents all other threads
> from running.
>
> The "official" 1.8.7 Windows build is OK, and so is a cygwin 1.8.7.
>
> You can replicate the problem with this:
>
> ---------------------------------------
> Thread.new do
>    while line = $stdin.gets
>      $stderr.puts ">>>  Received #{line.chomp}<<<"
>    end
> end
> i = -2
> loop do
>    $stderr.puts i
>    i += 1
>    sleep 2
> end
> ---------------------------------------
>
> Under the one-click installer 1.8.6, the printing loop freezes until you
> give it some input.

For the heck of it, I've tested 1.8.6 and 1.9.1 compiled with MinGW:
PS C:\Scripts> ruby -v
ruby 1.9.1p243 (2009-07-16 revision 24175) [i386-mingw32]
PS C:\Scripts> c:\ruby\bin\ruby -v
ruby 1.8.6 (2009-08-04 patchlevel 383) [i386-mingw32]

Ruby 1.9.1 performs as expected: The threads start, and i gets 
incremented every 2 seconds:
PS C:\Scripts> ruby .\thread.rb
-2
-1
0
1
2
3
14
1
 >>> Received 11 <<<
5
6
:q
 >>> Received :q <<<
7
8


Same script with 1.8.6:
PS C:\Scripts> c:\ruby\bin\ruby .\thread.rb
-2

 >>> Received  <<<
1
 >>> Received 1 <<<
-1
2
 >>> Received 2 <<<
0
:q
 >>> Received :q <<<
1
2

(Yeah, vim user here...)

It looks like 1.8.7 introduced (or rather got backported from 1.9) a 
change that makes threads work independent from the underlying OS.

--
Phillip Gawlowski