From: Eric Armstrong on
N Okia wrote:
>> I have cygwin running on my machine at home. What's
>> the best way to get ruby running on it?
> Startup the cygwin setup.exe program. Select Ruby from the list of
> packages to install. Finish the installation.
Spectacular. Didn't know about the program.
Thanks much.

From: Matt Lawrence on
On Sat, 29 Jul 2006, Sam Smoot wrote:

> I can appreciate the general Ruby community attitude that OS-Threading
> isn't absolutely vital when you're on Linux and have _fork_ at the
> ready, but under Windows it's very painful and really limits the types
> of applications you can build with Ruby (with a reasonable amount of
> effort) IME.

This has been brought up at previous Ruby Conferences. It is my
understanding that it is being worked on. So, relax and watch the
blinking lights.

-- Matt
It's not what I know that counts.
It's what I can remember in time to use.

From: Eric Armstrong on
Sam Smoot wrote:
> My experience has been that IO is blocking in Ruby/Windows. Just try
> creating a background thread to insert into an MSSQL server through
> WIN32OLE+ADO. It's an exercise in futility. :-)
Ah. That explains why the two counter threads
worked. There was no I/O going on. But outside
of computational supercomputers, there is zero
point in having threads if they don't let you
keep doing things while waiting for I/O.

> ...under Windows it's very painful and really limits the types
> of applications you can build with Ruby...
I'm forced to agree. My little application is dead in the
water. Windows users would have been a major market for it.
It would have helped drive ruby installs, which would have
helped to drive awareness. Similarly with game programs,
music programs, and a wide variety of other interesting

This limitation is a severe shot in the foot with respect
to platform independence.

From: Srinivas JONNALAGADDA on
On Sat, 2006-07-29 at 06:18 +0900, Eric Armstrong wrote:
> Below. And now that I'm at work, rather than
> at home, I've been able to determine that it
> works as expected on my Solaris box, but fails
> on Windows XP. (There, the display only updates
> after pressing spacebar or some other key.)

Here is an improvisation to your code. This automatically exits at the
end of the set timer, rather than wait for a 'q/Q' from the user.


require 'curses'
require 'thwait'

count = ARGV[0] ? ARGV[0].to_i : 100

Curses.addstr "I am going to count #{count}. Press 'q' or 'Q' to

threads =

timer_thread = do
count.downto(1) do |i|
sleep 1
threads.join_nowait timer_thread

wait_thread = do
while true
c = Curses.getch
case c
when ?q, ?Q
return true
threads.join_nowait wait_thread


From: Jan Svitok on
On 7/29/06, Eric Armstrong <Eric.Armstrong(a)> wrote:
> So how would you implement a simple keyboard-controller
> for threads on Windows?

Maybe you can use kbhit() and getch() from msvcrt.dll

kbhit returns whether there are any keystrokes in the buffer
getc returns them.

So, what I do is (or something similar, I don't have the exact code here):

kbhit ='msvcrt','kbhit',...)
getch = ...

def wait_for_keypress
while true
if kbhit.Call
ch = getch.Call while kbhit.Call # to flush the buffer
sleep 0.1 # this should allow other threads to run