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-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Orion Edwards Sent: Sunday, February 14, 2010 1:19 PM To: ironruby-core@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.
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
