Hacker News Reader

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?

View on HN

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.

Reply on news.ycombinator.com