Ruby 1.8 использует потоки пользовательского пространства, а не потоки операционной системы. Это означает, что Ruby 1.8 может использовать только одно ядро ЦП, независимо от того, сколько потоков Ruby вы создаете.
С другой стороны, не все так плохо. Ruby 1.8 внутренне использует неблокирующий ввод-вывод, а Ruby 1.9 разблокирует глобальную блокировку интерпретатора при выполнении ввода-вывода. Таким образом, если один поток Ruby заблокирован при вводе-выводе, другой поток Ruby может продолжить выполнение. Точно так же Ruby достаточно умен, чтобы такие вещи, как sleep() и даже waitpid(), вытесняли другие потоки.
Выше приведен отрывок из недавнего блога. пост от людей из Phusion.
Как MRI обрабатывает дисковый ввод-вывод внутри себя?
Из того, что я понял, неблокирующий дисковый ввод-вывод через select/epoll/kqueue невозможен, поскольку fds всегда будет доступен для чтения/записи. Поэтому я ожидаю, что MRI будет блокироваться, когда он выполняет файловый ввод-вывод, но если он блокируется, нет смысла писать многопоточную программу. Есть ли в MRI внутренний пул потоков, на который перенаправляются эти блокирующие вызовы ввода-вывода?
