On Jun 9, 2009, at 1:19 PM, James Gray <james / grayproductions.net>  
wrote:

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

You really can't do two things at once anyhow. You do multiple things  
"as if" at once. Actually, not true. On multiple cores you can do n  
things at once so long as they don't muck with a single shared  
resource. But my application of threading is very similar to the way  
we have been using drb. I know what parts of the app will block and  
bring things to their knees. Usually network or graphics related  
stuff. So these are ways I'd like to use some concurrent construct.

Threads have gotten a terrible reputation in 1.8 so on most cases they  
have been easy to ignore in favor of processes. If this (ignoring  
threads) is still the likely case in 1.9 then that would be good to  
know.

Thx

Steve

 From my iPhone