[zeromq-dev] Getting started with ruby bindings

[Chuck Remes]

On Apr 21, 2010, at 8:49 AM, Pieter Hintjens wrote:

> On Wed, Apr 21, 2010 at 3:33 PM, Martin Sustrik <sustrik at imatix.com> wrote:
> 
>> Ruby is basically a single OS thread + green Ruby threads, right?
> 
> Language != implementation of language.
> 
> See here http://stackoverflow.com/questions/56087/does-ruby-have-real-multithreading
> 
> 11 different runtimes (not 20 as I remembered).  JRuby is the only one
> (according to the article) with true threads.

Wow, that stackoverflow response is OLD.

At this point in time, there are only 7 ruby runtimes that get any attention and are usable in a production setting.

1. MRI 1.8.x
Green threads

2. MRI 1.9.x
Native threads with a GIL

3. JRuby (implements both 1.8 and 1.9 syntax)
Native threads or green (JVM dependent)

4. Rubinius
Native threads with a GIL
(The answer in stackoverflow is way out of date on this one.)

5. MacRuby
Native threads with a GIL

6. IronRuby
Native on Win32

7. MagLev
This is built on top of the GemStone Smalltalk application server. If it is threaded then MagLev will be too.


I haven't done a side-by-side comparison yet but I would *guess* that MRI 1.9.x will run 0MQ without the same problems as MRI 1.8.x. I wouldn't recommend MRI 1.8.x at all for any new projects; MRI 1.9.x is very solid and is where *all* new code development is happening for C Ruby. The 1.8.x branch is in maintenance mode.

BTW, the GIL (giant interpreter lock) used by many of these runtimes does *not* prevent C extensions from spawning as many threads as they want or need. All it does is serialize all access from the C extension back into the interpreter. Therefore, many threads *can* run simultaneously but only one can call back into ruby at any given time.

That said, I think JRuby will be fine but it will have JNI overhead. Perhaps I'll contribute some FFI bindings to 0MQ so it is usable (new weekend project).

cr