News for hackers. Stuff that matters.
Re:Why Use Rubinius by riffraff on Saturday February 26, 2011 @03:09AM (#2265136)
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?

Re:Why Use Rubinius by evanphx on Saturday February 26, 2011 @03:38AM (#2265163)
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.