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

> On Wed, Apr 21, 2010 at 3:33 PM, Martin Sustrik <sust...@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

_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to