Listening to the Ruby on Rails podcast... Rubinius developers have already demonstrated native threads running. Not only that, each Rubinius VM you spawn can have green threads. First preview of 1.0 release of Rubinius (running Ruby 1.8) will be May 15th. Right around the corner. 1.0 will not includethe native threads, but they are planned for 2.0 release of Rubinius. Likewise, Ruby 2.0 with YARV is planning native threads as well.
On top of that, Mentalguy is building an Actors library on top of Rubinius' capability to run native threads (Omnibus?). So very soon, Ruby will have a VM (written almost entirely in Ruby! with a small amount of C primitives = Rubinius)... that will enable native threads. Imagine the potential this has to reduce the memory footprint for Rails.
In addition, Merb (Mongrel + erb) has gained a lot of momentum as an option along with Rails.
Both Rubinius and Merb are both open source, but are funded by Engine Yard (Engine Yard has 5 full time developers working on Rubinius, for instance,... and Ezra Zygmuntowitz, the founder, is the creator of Merb)
great to see a lot of momentum for Ruby community...
From the Rubini.us website:
Concurrency
Rubinius provides a number of concurrency techniques, significantly expanding upon that available in standard Ruby. As such, use of these additional primitives is non-standard.
Note: Currently, Rubinius achieves concurrency through the use of green-threads. Native thread support is not implemented at present, although it is planned for the 2.0 release of Rubinius, and Shotgun has been constructed with thread-safety in mind.
Tasks
Tasks are the foundation of green threads in Rubinius. See here for an overview of Rubinius tasks.
Threads
Channels
Channels provide a simple mechanism for coordinating the work of two or more threads. A channel resembles a queue, in that producer thread(s) can write to the channel, while consumer thread(s) read from it. If there is no data currently in the channel, consumer threads will suspend until data is available.
Actors
The Actor class provides an implementation of the Actor concurrency pattern. Actor instances are threads that can be given work to do via message objects. Actor instances process messages according to filters, deciding what to do based on the type of message to be processed (where comparison of message types uses the same comparison logic as case, namely ===).
Unlike Channels, the read end of an Actor is fixed (to the thread owned by the Actor), and the Actor can prioritise handling of messages, and even postpone processing of messages for which no filter has yet been defined.
Actor.receive do |filter|
filter.when SomeMessageClass do |message|
# handle message
end
filter.when OtherMessageClass do |message|
# handle message
end
end
