On Fri, Mar 2, 2012 at 12:59 PM, Marc Lehmann <schm...@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
_______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
