nio4r and the Ruby GIL revisited

Tony Arcieri tony.arcieri at
Sat Mar 3 02:27:16 CET 2012

On Fri, Mar 2, 2012 at 12:59 PM, Marc Lehmann <schmorp at> wrote:

> Also, your solution seems to lack proper locking of the loop - unless ruby
> somehow guarantees that you need to avoid two threads running the same
> event loop. That could be achieved by putting a (recursive) mutex around
> the ev_run call.

I *believe* have that covered here:

This code is using the native Ruby mutex API via the C API. The only path
to ev_run goes through this function which locks the mutex for the duration
of the entire selection operation. This same mutex is acquired before
entering any libev code period.

> Well, the only place to fix this is in ruby, because thats where the
> problem
> is. The abstraction ruby chose is wrong, and unlike any other lock
> implementation.

You're preaching to the choir, and this is probably actually one of the
*less* egregious defects in Ruby when it comes to their I/O API. I don't
even want to get into how they implemented their non-blocking APIs, but let
me put it this way: it involves exceptions. This is what happened when
someone submitted a patch that tries to fix it, which still sits in limbo:

Because of this, I am very strongly considering running all I/O through C
extensions which bypass this ugly API.

I can request they change the global interpreter lock API, because I agree
it is obviously wrong and I *need* the ability to granularly lock and
unlock the global interpreter lock here, but ruby-core is
characteristically reluctant to make these sorts of changes.

Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the libev mailing list