In this article, we interview the maintainers of two projects that use Ruby 1.9's Fibers to make non-blocking I/O easy to use.
After Rails is finally on track to be threadsafe, the use of non-blocking I/O is necessary to make the most of running multiple Rails requests in one Ruby instance. The problem: some of the current database adapters block during the runtime of a database request. By using the non-blocking versions of the database drivers and using Fibers to make the process as transparent as possible, the Neverblock library allows to keep the Rails runtime busy. Starting out with a PostgreSQL driver, MySQL support is now available. We talked to Mohammad A. Ali from the Neverblock project.
A more longterm solution for scalability is the use of Erlang-style Actors. Revactor aims to provide Actors on Ruby 1.9 using Fibers. We talked to Tony Arcieri, the creator of the project.
Read the interviews in the article "Using Ruby Fibers for Async I/O: NeverBlock and Revactor".
After Rails is finally on track to be threadsafe, the use of non-blocking I/O is necessary to make the most of running multiple Rails requests in one Ruby instance. The problem: some of the current database adapters block during the runtime of a database request. By using the non-blocking versions of the database drivers and using Fibers to make the process as transparent as possible, the Neverblock library allows to keep the Rails runtime busy. Starting out with a PostgreSQL driver, MySQL support is now available. We talked to Mohammad A. Ali from the Neverblock project.
A more longterm solution for scalability is the use of Erlang-style Actors. Revactor aims to provide Actors on Ruby 1.9 using Fibers. We talked to Tony Arcieri, the creator of the project.
Read the interviews in the article "Using Ruby Fibers for Async I/O: NeverBlock and Revactor".
