nio4r and the Ruby GIL revisited
tony.arcieri at gmail.com
Sat Mar 3 02:27:16 CET 2012
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:
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
> is. The abstraction ruby chose is wrong, and unlike any other lock
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libev