From: Eleanor McHugh Date: 2009-06-10T00:07:23+09:00 Subject: Re: Ruby 1.9.x Concurrency On 9 Jun 2009, at 15:16, James Gray wrote: > On Jun 9, 2009, at 1:23 AM, s.ross wrote: >> Poking through the Apple press releases today, I sat up and took >> notice when I saw that they were putting a fair amount of pretty >> public emphasis on concurrency as the silver bullet for faster >> computing when Snow Leopard comes out. If we stipulate that >> concurrency is fundamentally a good solution of a certain class of >> problems, here were the questions I immediately had: >> >> - My understanding is that the 1.9 implementation of threads is to >> use native threads. But the caveat is that the GIL is still in >> place. What does this mean in practice as it applies to increasing >> throughput by distributing load across processor cores? >> >> - I'm trying to parse the fiber vs. thread distinction and it feels >> to me like fibers are a leaner, meaner version of the 1.8.x green >> threads, but that they will always run on the same core. Am I >> missing something here? > > What I think you're getting at here is, yes, threading still isn't > the way to get real concurrency on Ruby 1.9. If you really want to > do two things at once, you're going to need processes in Ruby. Indeed. And on a Unix box (like Snow Leopard) there really isn't a good excuse for ignoring them unless your concurrency needs are pretty trivial. Use threads for simple things like downloading multiple web pages concurrently, but for significant processing jobs chuck your data down a pipe to a process and let the OS take care of proper scheduling etc. And for some quick coverage of this sort of thing grab the "Ruby Plumber's Guide" presentation from the link in my sig, or wait for James's RubyKaigi presentation which I suspect will be both more coherent and more detailed :) Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net ---- raise ArgumentError unless @reality.responds_to? :reason