On Jun 9, 2009, at 1:11 PM, s.ross wrote:

> 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.

While threading does solve that problem in some languages, it not  
really for that in Ruby.  In Ruby, threading is for separating off  
action that will need to wait at some point (generally on I/O  
operation) so you can keep working on other things while they do.

> 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."

Sure.  Your Thread paused waiting for the database I/O, but the rest  
of the application kept moving.  That's a good example of where Ruby's  
threads help.

> 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).

Again, at each Thread hit a waiting period, others had a chance to  
run.  When it was single threaded, you had to serially wait through  
each pause.

The important thing to realize about all of the above is that they  
didn't go faster because you were suddenly doing more than one thing  
at a time.  MRI doesn't do that.  You just arranged to spend less time  
waiting.  That's nice, but it's not true concurrency.

> 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?

When you really want to do two things at once with Ruby, you want more  
processes.  fork() is your friend.  :)

James Edward Gray II