From: "s.ross" <cwdinfo@...>
Date: 2009-06-10T03:11:05+09:00
Subject: Re: Ruby 1.9.x Concurrency

Thanks for all the answers. I guess the main issue I'm trying to get  
my head around is that since Moore's law doesn't quite seem to be  
keeping up with the demand for processing power, multi-code and multi- 
processor hardware solutions are predominant in the field now. The  
question I'm trying to answer is not how great the threading solution  
is but rather whether the threading solution solves the problem of  
distributing workload without incurring more overhead than it's worth.

I implemented a simple MacRuby app that just fills a list from a  
database. Doing the database query and populating the 20 or so items  
that show at any given time still gave the app a kind of sluggish  
feel. Once I separated this into a separate thread, removing the  
block, the simple fact that the UI was alive made the app seem  
"perkier."

More to the point, I created an app using MRI that relied on  
downloading a boatload of information from a Web service. Single  
threaded, this took about 20 minutes, where using multiple threads, it  
was accomplished in 3-5 minutes. However, this one involves a good  
deal of trickery so as not to step on buffers in the net/http  
libraries (or something underlying).

So I come back to the question: As we find ourselves with resources  
that scale across processing units, how best does Ruby solve the  
problem and what role do Fibers play in that solution, if any?

Thanks again,

Steve


On Jun 9, 2009, at 10:44 AM, Tony Arcieri wrote:

> On Tue, Jun 9, 2009 at 10:06 AM, Charles Oliver Nutter
> <headius@headius.com>wrote:
>
>> Or just use JRuby, and real concurrent/parallel threads will just  
>> work
>> out of the box :)
>>
>
> Well, as best they can on Ruby.  You guys have done some really  
> great work
> on that, but Ruby's approach to threading is rather poor.
>
> -- 
> Tony Arcieri
> medioh.com