I hate to make a plug here, but threads under JRuby are native and a single
one blocking on IO will not prevent others from running. It's still quite a
bit slower than C Ruby, but for many applications it's definitely fast
enough.
Ruby 2.0 is supposed to have native threads too, but I know that 18+ months
is a long time to wait.
···
On 7/28/06, Eric Armstrong <Eric.Armstrong@sun.com> wrote:
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
applications.
This limitation is a severe shot in the foot with respect
to platform independence.
--
Contribute to RubySpec! @ Welcome to headius.com
Charles Oliver Nutter @ headius.blogspot.com
Ruby User @ ruby.mn
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com
What happens if you just use select to read the file descriptor associated
with stdin? On Windows iirc, this descriptor is already raw. For Solaris etc
you can just make it raw with termio calls.
···
On 7/29/06, Eric Armstrong <Eric.Armstrong@sun.com> wrote:
Nice! Didn't know about that kbhit.
That has promise. I wonder if there is a
multi-platform version of that API?
Ezra Zygmuntowicz wrote:
Have a look at the highline gem. Its a great library for console based question and menu systems. And it works with threading.
Could be a useful option. Thanks for the tip.
Found it's main page at
http://highline.rubyforge.org/
Is there a starter app anywhere? I see the APIs.
I'm guessing I do something like this:
ifc = HighLine.new
ifc.say "xyz"
response = ifc.ask "xyz"
But it would be nice to have a little scaffolding
to start from...
I assume I'm misreading you but it sounds like you're saying that Ruby's
green threads block whole processes on I/O. This is not true. I've hit the
Windows-specific problem that is the subject of this thread several times
and I think it's either a Ruby-build issue or a Windows-specific
implementation bug. It shouldn't take 18+ months to find and fix it.
···
On 7/28/06, Charles O Nutter <headius@headius.com> wrote:
I hate to make a plug here, but threads under JRuby are native and a
single
one blocking on IO will not prevent others from running. It's still quite
a
bit slower than C Ruby, but for many applications it's definitely fast
enough.
Francis Cianfrocca wrote:
···
On 7/29/06, Eric Armstrong <Eric.Armstrong@sun.com> wrote:
Nice! Didn't know about that kbhit.
That has promise. I wonder if there is a
multi-platform version of that API?
What happens if you just use select to read the file descriptor associated
with stdin? On Windows iirc, this descriptor is already raw. For Solaris etc
you can just make it raw with termio calls.
Sounds promising. Do you have a bit of code
to go with the suggestion, perchance?
(I'm having a bit of trouble filling in the blanks.)