IronRuby maps Ruby''s green threads directly to CLR threads, and there
is no GIL.
The best documentation is just to look through
IronRuby.Builtins.ThreadOps<http://github.com/ironruby/ironruby/blob/master/Merlin/Main/Languages/Ruby/Libraries.LCA_RESTRICTED/Builtins/ThreadOps.cs>
=P. Here''s the first comment:
/// Ruby threads are represented by CLR thread objects
(System.Threading.Thread).
/// Ruby 1.8.N has green threads where the language does the thread
scheduling.
/// We map the green threads directly to CLR threads.
~js
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Orion Edwards
Sent: Sunday, February 14, 2010 1:19 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Threading model
Here is what I *think* happens:
- Thread.new and the other ruby threading methods from the ruby standard
library will create and run on new CLR threads, but there is ''global
interpreter lock'' type thing to emulate MRI
- I can sidestep the GIL by explicitly using underlying CLR threading methods
This is based entirely on speculation and "I thought I saw something about
it once upon a time"
Is there a page that explains what the threading model of IronRuby is? I would
be happy to write one up on the wiki, but I have no idea what is actually going
on.
Thanks, Orion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100214/9a039313/attachment-0001.html>