Ruby 1.8 は、オペレーティング システムのスレッドではなく、ユーザー空間のスレッドを使用します。つまり、Ruby 1.8 は、作成する Ruby スレッドの数に関係なく、単一の CPU コアしか利用できません。
明るい面では、すべてが悪いわけではありません。Ruby 1.8は内部的にノンブロッキング I/Oを使用しますが、Ruby 1.9 は I/O の実行中にグローバル インタープリター ロックを解除します。そのため、1 つの Ruby スレッドが I/O でブロックされても、別の Ruby スレッドが実行を継続できます。同様に、Ruby は十分に賢いので、sleep() や waitpid() などを他のスレッドにプリエンプトします。
上記は、Phusion 関係者による最近のブログ投稿からの抜粋です。
MRI はディスク I/O を内部でどのように処理しますか?
私が収集したものから、select/epoll/kqueue を介してノンブロッキング方式でディスク I/O を実行することは不可能fdsです。したがって、MRI がファイル I/O を行うときにブロックすることを期待しますが、ブロックする場合は、マルチスレッド プログラムを作成しても意味がありません。MRI には、これらのブロッキング I/O 呼び出しがオフロードされる内部スレッド プールがありますか?