Updated with Jörg's Sept 2011 comment
You seem to be confusing two very different things here: theRuby Programming Language and the specific threading model of onespecific implementation of the Ruby Programming Language. Thereare currently around 11 different implementations of the RubyProgramming Language, with very different and unique threadingmodels.
(Unfortunately, only two of those 11 implementations are actuallyready for production use, but by the end of the year that numberwill probably go up to four or five.) (Update: it's now 5: MRI, JRuby, YARV (the interpreter for Ruby 1.9), Rubinius and IronRuby).
- The first implementation doesn't actually have a name, whichmakes it quite awkward to refer to it and is really annoying andconfusing. It is most often referred to as "Ruby", which is evenmore annoying and confusing than having no name, because itleads to endless confusion between the features of the RubyProgramming Language and a particular Ruby Implementation.
It is also sometimes called "MRI" (for "Matz's RubyImplementation"), CRuby or MatzRuby.
MRI implements Ruby Threads as Green Threads within itsinterpreter. Unfortunately, it doesn't allow those threadsto be scheduled in parallel, they can only run one thread at atime.
However, any number of C Threads (POSIX Threads etc.) can runin parallel to the Ruby Thread, so external C Libraries, or MRIC Extensions that create threads of their own can still run inparallel.
- The second implementation is YARV (short for "YetAnother Ruby VM"). YARV implements Ruby Threads as POSIX orWindows NT Threads, however, it uses a Global InterpreterLock (GIL) to ensure that only one Ruby Thread can actually bescheduled at any one time.
Like MRI, C Threads can actually run parallel to Ruby Threads.
In the future, it is possible, that the GIL might get brokendown into more fine-grained locks, thus allowing more and morecode to actually run in parallel, but that's so far away, it isnot even planned yet.
JRubyimplements Ruby Threads as Native Threads,where "Native Threads" in case of the JVM obviously means "JVMThreads". JRuby imposes no additional locking on them. So,whether those threads can actually run in parallel depends onthe JVM: some JVMs implement JVM Threads as OS Threads and someas Green Threads. (The mainstream JVMs from Sun/Oracle use exclusively OS threads since JDK 1.3)
XRuby also implements Ruby Threads as JVM Threads. Update: XRuby is dead.
IronRubyimplements Ruby Threads as Native Threads,where "Native Threads" in case of the CLR obviously means"CLR Threads". IronRuby imposes no additional locking on them,so, they should run in parallel, as long as your CLR supportsthat.
Ruby.NET also implements Ruby Threads as CLRThreads. Update: Ruby.NET is dead.
Rubiniusimplements Ruby Threads as Green Threadswithin its Virtual Machine. More precisely: the RubiniusVM exports a very lightweight, very flexibleconcurrency/parallelism/non-local control-flow construct, calleda "Task", and all other concurrency constructs (Threads inthis discussion, but also Continuations, Actors andother stuff) are implemented in pure Ruby, using Tasks.
Rubinius can not (currently) schedule Threads in parallel,however, adding that isn't too much of a problem: Rubinius canalready run several VM instances in several POSIX Threads inparallel, within one Rubinius process. Since Threads areactually implemented in Ruby, they can, like any other Rubyobject, be serialized and sent to a different VM in a differentPOSIX Thread. (That's the same model the BEAM Erlang VMuses for SMP concurrency. It is already implemented forRubinius Actors.)
Update: The information about Rubinius in this answer is about the Shotgun VM, which doesn't exist anymore. The "new" C++ VM does not use green threads scheduled across multiple VMs (i.e. Erlang/BEAM style), it uses a more traditional single VM with multiple native OS threads model, just like the one employed by, say, the CLR, Mono, and pretty much every JVM.
MacRuby started out as a port of YARV on top of theObjective-C Runtime and CoreFoundation and Cocoa Frameworks. Ithas now significantly diverged from YARV, but AFAIK it currentlystill shares the same Threading Model with YARV.Update: MacRuby depends on apples garbage collector which is declared deprecated and will be removed in later versions of MacOSX, MacRuby is undead.
Cardinal is a Ruby Implementation for the ParrotVirtual Machine. It doesn't implement threads yet, however,when it does, it will probably implement them as ParrotThreads. Update: Cardinal seems very inactive/dead.
MagLev is a Ruby Implementation for the GemStone/SSmalltalk VM. I have no information what threading modelGemStone/S uses, what threading model MagLev uses or even ifthreads are even implemented yet (probably not).
HotRuby is not a full Ruby Implementation of itsown. It is an implementation of a YARV bytecode VM inJavaScript. HotRuby doesn't support threads (yet?) and when itdoes, they won't be able to run in parallel, because JavaScripthas no support for true parallelism. There is an ActionScriptversion of HotRuby, however, and ActionScript might actuallysupport parallelism. Update: HotRuby is dead.
Unfortunately, only two of these 11 Ruby Implementations areactually production-ready: MRI and JRuby.
So, if you want true parallel threads, JRuby is currently youronly choice – not that that's a bad one: JRuby is actually fasterthan MRI, and arguably more stable.
Otherwise, the "classical" Ruby solution is to use processesinstead of threads for parallelism. The Ruby Core Librarycontains the Process module with the Process.forkmethod which makes it dead easy to fork off another Rubyprocess. Also, the Ruby Standard Library contains theDistributed Ruby (dRuby / dRb) library, which allows Rubycode to be trivially distributed across multiple processes, notonly on the same machine but also across the network.
