From: Jacek Olszak <jacekolszak@...2.pl>
Date: 2006-01-09T03:15:42+09:00
Subject: Re: Newbie question about threads and gets

Bill Kelly wrote:
> From: "Jacek Olszak" <jacekolszak@o2.pl>
>> b=Thread.new do
>> Unfortunelty "gets" block my whole application - the "b" thread waits 
>> until user writes something to the stdin. But I want the b thread not 
>> wait and run at the same time.
> 
> This tends to be a problem with Windows ruby.  It seems unlikely to be
> resolved until Ruby gets native threads (on the horizon with YARV.)
> 

Yes.. I'm using winxp currently :(

> Here's how I've worked around it.  If anyone knows a better way, please
> share:
> 
> if RUBY_PLATFORM =~ /win32/
>   require 'Win32API'
>   $win32_console_kbhit = Win32API.new("msvcrt", "_kbhit", [], 'I')
>   def console_input_ready?
>     $win32_console_kbhit.call != 0
>   end
>   def nonblocking_stdin_gets
>     sleep(0.1) until console_input_ready?
>     $stdin.gets  # don't bother to use getc, it also blocks until user 
> hits <return>
>   end
> else
>   def nonblocking_stdin_gets
>     $stdin.gets   # it just works, on unix
>   end
> end
> 
> So you can use nonblocking_stdin_gets in place of $stdin.gets.  It's an
> imperfect solution, though.  It will be nonblocking _until_ the user 
> starts
> typing.  Then it will block until they hit <return>.  (Note, I've tried 
> doing
> it character-by-character, with $stdin.getc or $stdin.sysread(1), but it
> still blocks until the user hits <return>.)  There's probably a way to 
> put
> the windows console into unbuffered mode, which would improve this
> hack (so we could use $stdin.getc in conjunction with 
> console_input_ready?.)
> 
> Anyway, hope this helps . . .
> 
> Regards,
> 
> Bill


Thanks a lot Bill! Maybe it is not a perfect solution, but quite useful 
for me at the moment :)

P.S. I'm going to change my os till midnight ;)

-- 
Posted via http://www.ruby-forum.com/.