

Ruby Threads and the Global Interpreter Lock in C - montanalow
https://www.omniref.com/ruby/2.2.0.preview1/files/thread_pthread.h#annotation=4057266&line=38

======
sandstrom
It mentions Rubinius briefly (it doesn't have a GIL).

Slightly of topic, but can anyone with better knowledge then myself of ruby
implementations and internals explain why it hasn't caught much of a following
(what it seems anyway, I may be wrong here).

To me it seems like a pretty good idea to implement Ruby mostly in Ruby, since
it makes it easier to get contributions (especially to less performance-
sensitive parts of the language, e.g. parts of the standard lib).

~~~
montanalow
Rubinius is neat, but for me personally (and I think most of the community)
it's performance. Writing C enables optimizations by hand that still yield
very significant performance gains over the best of what any other high level
language (java, c++, ruby) can muster. I don't want to write C, but I'm glad
someone else does so I get the benefits when I write Ruby.

~~~
FranzVonSuppe
I don't understand how you can say Java, C++, and Ruby in the same breath.
They are not at all alike. Also what optimizations are available to C which
are not in C++? C++ is (almost) a strict superset of C.

~~~
Argorak
Just because C++ is a superset of C doesn't mean that all C++ features are in
a way comparable to C (in compiling and at runtime).

------
hardwaresofton
Did anyone notice a popup box asking you if you "didn't find what you were
looking for"?

it appeared almost automatically after I moved my mouse to close the tab...
Are they doing some mouse tracking and looking for rapid movement off screen
(to the top of the page)?

If so, that's really cool. If not, nevermind

~~~
girvo
I triggered it on purpose when I saw your post, by pretending to close the
tab. Pretty neat trick!

~~~
hardwaresofton
Yeah, it looks like they even do it maybe once per IP - I tried to reproduce
it but couldn't, even in incognito mode.

Glad I wasn't crazy

------
pmontra
This 3 parts series from 2013 explains in details how the GIL works
[http://www.jstorimer.com/blogs/workingwithcode/8085491-nobod...](http://www.jstorimer.com/blogs/workingwithcode/8085491-nobody-
understands-the-gil)

Disclaimer: it's linked in the omniref.com page too.

------
towski
The only question I have is, how much work is it to create a C based ruby
without a global interpreter lock.

~~~
montanalow
Matz mentioned off hand at the last Ruby Conf that Nobu has been experimenting
without the GIL. It's scary because running code without the GIL will expose a
lot of existing concurrency bugs that have been safely hidden thus far. A lot
of code works fine with the GIL, since it prevents the full parallelism that
would exercise all possible race conditions, so it's unlikely they'd remove it
in anything other than a major release, i.e. Ruby 3.0

~~~
masklinn
An other issue, the one CPython has hit repeatedly when trying to remove the
GIL — and the big sticking point for the core team in general — is that
single-threaded performances of a naive interpreter suffer _a lot_ when
splitting the GIL: instead of a single lock which is taken and released
relatively rarely, the interpreter has to juggle with many small locks which
it has to acquire and release much more often. When David Beazley looked back
on the GIL-less patch for CPython 1.4[0] he measured performance hits of
4x~7x.

Though in the case of CPython most of the cost comes from the refcounting. MRI
is not refcounted so the performance hit of finer locking would probably be
lower.

[0] [http://dabeaz.blogspot.be/2011/08/inside-look-at-gil-
removal...](http://dabeaz.blogspot.be/2011/08/inside-look-at-gil-removal-
patch-of.html)

~~~
jordanthoms
This is where JRuby / Truffle is exciting - JRuby's been exciting for a long
time and never quite reached it's potential, but with these latest projects it
could become the main ruby implementation - and these complex issues are
already largely solved in the JVM.

~~~
stormbrew
I really doubt jruby will ever become the main ruby implementation, as awesome
as it is. The fact is that too much of the ruby ecosystem is built on calling
out to C, and jruby officially abandoned cext shimming a while back. And while
ffi is good, it's often not nearly as flexible.

There's also the fact that because of slow startup times, the modify/test
cycle can be quite frustrating compared to working with MRI.

The truth is that the vast majority of ruby applications never reach a point
where the steady-state post-warmup performance of jruby with pure ruby
outweighs the fast-startup moderate performance of mri+cexts. And ones that do
reach that point often have a better case for moving to something else anyways
(including other jvm technologies that can now be shimmed on via jruby and
eventually replace the whole thing).

~~~
rurounijones
> C, and jruby officially abandoned cext shimming

Jruby + truffle + cext, however is becoming a possibility.

[http://www.chrisseaton.com/rubytruffle/cext/](http://www.chrisseaton.com/rubytruffle/cext/)

~~~
stormbrew
Huh. That is a really interesting approach, and I was not aware of it. Thanks.

I haven't looked deeply, but this seems like something where the edge cases
will be tricky, though.

