Comments on: Concurrency is a Myth in Ruby

By: Ilya Grigorik

Ilya Grigorik — Sun, 07 Feb 2010 20:24:13 +0000

MacRuby drops the GIL as well. You might want to try their new GCD (grand central dispatch) API’s as well for coordinating the work - check their blog.

By: 5v3n

5v3n — Sun, 07 Feb 2010 15:18:01 +0000

Nice article - I was wondering why my multi threaded approach didn’t seem to accelerate & your post was very helpful to find the explanation. JRuby did the trick.

I’m going to test it with MacRuby, too - I couldn’t find any hints on the concurrency behaviour yet, but my benchmarks will show.

Cheers

5v3n

By: Klank Boom Klang » Ruby in a multicore world

Klank Boom Klang » Ruby in a multicore world — Sun, 01 Nov 2009 01:17:27 +0000

[...] 1.9 internal threading models differ significantly, the exposed concurrency model is fundamentally the same. Unlike Ruby 1.8, Ruby 1.9 threads do map to native threads, unfortunately the 1.9 interpreter [...]

By: Ilya Grigorik

Ilya Grigorik — Wed, 01 Jul 2009 02:30:13 +0000

Corbin, Rails has become ‘thread-safe’ as of 2.3 release. There are still a few nasty locks in the router and a few other places, but there is a lot of progress in that area.

In terms servers, Phusion Passenger is a good option to explore - no need to worry about number of workers, etc.

By: corbin

corbin — Tue, 30 Jun 2009 14:41:38 +0000

Thanks IIyan…very informative. I was under the impression that Rails wasn’t thread-safe so it blocked on every request.
It just seems like the “other” camps have a much better server story than Ruby.

I’d like to learn more thanks for sharing your knowledge. Very nice article/diagrams.

By: Ilya Grigorik

Ilya Grigorik — Tue, 30 Jun 2009 13:06:49 +0000

Yes! In fact, Twitter guys oversubscribe each core by running 2x Mongrels on each core. Check out their presentation at Velocity ‘09 (google for it).

By: sbwoodside

sbwoodside — Tue, 30 Jun 2009 06:49:13 +0000

That would seem to imply that I should really be running four mongrels on my quad-core system, then?

By: Ilya Grigorik

Ilya Grigorik — Tue, 30 Jun 2009 06:15:40 +0000

Corbin, almost but not quiet. This really depends on a number of external factors. For example, by default Mongrel is a threaded web-server, which means that every new request is spun out into a separate thread. Beyond that, the VM takes over. If one of the requests blocks without locking the VM, then another thread will run in it’s place - giving you interleaved execution. Having said that, if the request blocks the VM then the world is suspended until it returns (ex: poorly implemented gems).

Why should you run multiple mongrels? One to guard against the case I describe above. Two, to take advantage of multi-core CPU’s!

By: corbin

corbin — Mon, 29 Jun 2009 20:39:06 +0000

So if I understand correctly mongrels aren’t going to be able to serve multiple requests per process anytime soon? It’s kind of a killer to have to start 4 mongrels just to serve 4 simultaneous web requests. Processes are great but if we can’t share any of the libraries and code like Rails each process becomes pretty hefty!

By: MySchizoBuddy

MySchizoBuddy — Thu, 18 Jun 2009 07:52:58 +0000

@roger
MacRuby 0.5 is to completely replace YARV with LLVM
http://macruby.com/blog/2009/03/28/experimental-branch.html