From: Joel VanderWerf <vjoel@...>
Date: 2009-09-11T08:17:39+09:00
Subject: Re: Asynchronous http POST?

Ivan Shevanski wrote:
> http://www.rubycentral.com/pickaxe/tut_threads.html
> 
> """
> Multithreading
> 
> Often the simplest way to do two things at once is by using Ruby 
> threads. These are totally in-process, implemented within the Ruby 
> interpreter. That makes the Ruby threads completely portable---there is 
> no reliance on the operating system---but you don't get certain benefits 
> from having native threads. You may experience thread starvation (that's 
> where a low-priority thread doesn't get a chance to run). If you manage 
> to get your threads deadlocked, the whole process may grind to a halt. 
> (!!!)  And if some thread happens to make a call to the operating system 
> that takes a long time to complete, all threads will hang until the 
> interpreter gets control back. (!!!)    However, don't let these 
> potential problems put you off---Ruby threads are a lightweight and 
> efficient way to achieve parallelism in your code.
> """

Here's my relatively naive understanding of the situation (for MRI, 1.8):

System calls will block all threads, except in a few cases. The 
exceptions include:

1. Waiting on IO. Ruby's threads are really an abstraction over a single 
native thread calling select() on all the file descriptors that the ruby 
threads are waiting on. When a fd is ready for reading, say, the native 
thread starts executing the ruby thread that was waiting for that fd.

2. Starting processes and waiting for them to finish. This is why

  Thread.new { system "long-running process" }

is a useful idiom (and it even works on windows).

Still, if you expect a lot of threads, EM will probably be much more 
efficient instead.

But many other system calls (#flock without the nonblock flag, for 
example) will block all ruby threads.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407