em-synchrony's problem is it has people wrap asynchronous libraries one-at-a-time. There's a few problems with that: You're exposing a synchronous API, but sti

em-synchrony's problem is it has people wrap asynchronous libraries one-at-a-time. There's a few problems with that: You're exposing a synchronous API, but still can't take advantage of the huge ecosystem of Ruby libraries that already expose synchronous APIs. Wrapping libraries becomes a one-off chore. Each individual library must be wrapped to work in an em-synchrony system, and if the libraries aren't both asynchronous and wrapped in fibers you can't use them. This not only shrinks the ecosystem of libraries further, but is also more error-prone than providing a general coroutine abstraction around socket IO. Providing a generalized abstraction for doing synchronous I/O with sockets/fibers and an evented backend is exactly what I'm working on in Celluloid::IO: https://github.com/tarcieri/celluloid-io https://github.com/tarcieri/celluloid-io