From: Robert Klemme <bob.news@...>
Date: 2005-09-27T22:51:42+09:00
Subject: Re: Ruby Threads 101

Ben wrote:
> On 9/26/05, Robert Klemme <bob.news@gmx.net> wrote:
>> I once cooked something up on the Wiki (including a superfluous queue
>> implementation - there is one that comes with Ruby) although I guess
>> it won't be much use for you as you seem to be rather senior when it
>> comes to threading.
>> http://www.rubygarden.org/ruby?MultiThreading
>>
>> One thing to keep in mind is that Ruby threads are not (yet) native
>> threads. Despite of that they work quite nicely IMHO.
>
>   Thanks for the wiki pointer.  It's always nice to see how something
> familiar is done in another language.  Gives me a feeling for what the
> differences are.
>
>   Why is it that Ruby threads aren't native?  Lack of time to make
> them so, or is it the long term plan to never use native threads?

No, AFAIK it's planned to use native threads in Ruby 2.  I believe the
reason behind the current design is portability (at the time Ruby was
created).  Matz?

>   Also, the book was a little vague about when all threads block
> waiting for one thread.  It said a "call to the operating system"
> would cause all threads to block.  What did that mean exactly?  Shell
> commands?  Opening files?  Sockets?  A lot of common actions results
> in system calls.

Yes.  IO is done nonblocking under the hood so you don't have to fear that
while reading from a file no other thread can be active.  Other than that
since Ruby threads are completely user space the interpreter has no way to
make a context switch between system calls.  But usually this is not a
problem apart from DNS lookups that sometimes seem to make scripts slow.

>   As for my project, I am considering having the group write an app
> that downloads fantasy football stats for several different positions
> from a web page.  (Each position would be grabbed and parsed by a
> different thread).  Those stats would be scored and each positions
> players would be sorted by score.  A shared table sorted by overall
> score would be updated on a player by player basis.
>
>   DId that make sense?  Thoughts?

Sounds ok for a first bit.  You have at least one shared resource (the
table) and can extend that with different approaches to thread creation
(create a thread per position, create n threads and let them do the work
farmer-worker like etc.).

Kind regards

    robert