Ruby 1.8 and disk I/O in a multi-threaded setting

Ruby 1.8 uses userspace threads, not operating system threads. This means that Ruby 1.8 can only utilize a single CPU core no matter how many Ruby threads you create.

On the bright side, not all is bad. Ruby 1.8 internally uses non-blocking I/O while Ruby 1.9 unlocks the开发者_开发技巧 global interpreter lock while doing I/O. So if one Ruby thread is blocked on I/O, another Ruby thread can continue execution. Likewise, Ruby is smart enough to cause things like sleep() and even waitpid() to preempt to other threads.

The above is an excerpt from a recent blog post by the Phusion folks.

How does MRI handle disk I/O internally?

From what I gather, doing disk I/O in a non-blocking manner via select/epoll/kqueue is not possible since the fds will always be readable/writeable. So I would expect MRI to block when it does file I/O, but if it blocks there's no point in writing a multi-threaded program. Does MRI have an internal thread-pool to which these blocking I/O calls are offloaded to?

Yehuda Katz, one of the core contributors to Rails 3, has blogged about this in some detail: http://yehudakatz.com/2010/08/14/threads-in-ruby-enough-already