nio4r and the Ruby GIL revisited

[Tony Arcieri]

On Fri, Mar 2, 2012 at 12:59 PM, Marc Lehmann <schmorp at schmorp.de> 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:

https://github.com/tarcieri/nio4r/blob/master/ext/nio4r/selector.c#L161

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:

http://bugs.ruby-lang.org/issues/5138

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: <http://lists.schmorp.de/pipermail/libev/attachments/20120302/0db9cac6/attachment.html>