David Masover wrote:
> The question you should be asking is, "What's the best way to handle
> concurrency in Ruby?" The answer is, it depends what you're doing, but 
> it's
> probably not threads.

I agree that it depends on what you're doing - but Ruby threads *are* 
often useful, especially when used in a coarse-grained way.

For example, suppose you have a bunch of objects and each is opening a 
HTTP connection to some remote server and pulling down content, and you 
want this to happen concurrently. Each object is essentially 
self-contained. Having these doing concurrent downloads within threads 
is straightforward to program and pretty robust.

The alternatives aren't pretty: rewrite your application in an 
event-driven way (so you have to find a HTTP client library which works 
this way too), or fork off separate processes (which then have to 
communicate back to the central one with the results, which might mean 
select'ing across the children, or using the filesystem as a temporary 
data store)

Not every application has to be mega-scalable and bombproof; a Sinatra 
web app with a handful of concurrent clients might usefully use threads 
too.

Of course, the assumption here is that you're programming in Ruby. If 
you want to avoid threads (which I agree is a good thing to do) and 
still have concurrency, then it might be better to switch to Erlang 
rather than jump through hoops in Ruby.
-- 
Posted via http://www.ruby-forum.com/.