[wycats]

A few points:

a) The ruby standard library is written in Ruby and is actually surprisingly well-behaved from a threading perspective. The code is not super-pretty, but it uses appropriate locking strategies and has been well-tested in threaded environments. All three major implementations (JRuby, MRI and Rubinius) share the vast majority of the Ruby standard library, so if JRuby works, Rubinius will work.

2) For the part of MRI written in C (which Rubinius calls the "kernel"), Rubinius has reimplemented the entire thing mostly in Ruby with some primitives. Since they own that code, it is their responsibility to define its semantics when run in parallel.

3) Rubinius implements its locking classes (like Mutex and ConditionVariable, see https://github.com/evanphx/rubinius/blob/master/lib/thread.r...) on top of its own low-level Channel implementation (see https://github.com/evanphx/rubinius/blob/master/kernel/boots...), which can be used to implement more sophisticated locking strategies. They have been working on this for a long time, and have been planning for it even longer.

[riffraff]

grandparent was probably thinking of how you avoid the GIL if existing extensions are written expecting to be used by a single thread.

Since rubinius provides the same C-api ruby does (ignoring FFI for now) wouldn't all the accesses to external libraries need to be wrapped in a shared big lock?

[evanphx]

For the time being, we use a lock that has to be held to run methods defined in C extensions, a GEL (Global Extension Lock) if you will.

We've got some other ideas to increase concurrency in extensions, but the crux is that yes, we have to perform some locking because people wrap thread unsafe libraries.

Because Rubinius does not use the C-API to implement anything in the core, this doesn't impact general concurrency.