2005-08-25
■[design]リソースの使用制限
先日、スレッドをたくさん生成する実験をしていて気づいたが、カーネルが最後の物理ページまでアロケートし尽くしてしまったら、その後のカーネルはサービスができなくなってしまう。自分としてはそれでも、「システムが動作を続けるならば、それでいいだろう」という考えであった。しかし、カーネルの信頼性という観点からは、この設計は非常にマズイ。
今のところ、Prexが扱う以下の全てのカーネル・リソースは、メモリの許す限りいくらでも生成することができる。
よく市販のRTOSで、最大タスク数、最大スレッド数などがデータ・シートに記載されているところを見ると、それらの数が多い方が柔軟なシステムとみなされているようだ。確かにリソースの上限は少ないよりは多いほうがスケーラブルだ。自分もそれは意識していて、Prexでも意図的にリソースの上限の設定を避けてきた。
しかし、例えばある特定のアプリケーションが、バグあるいは意図して無限のスレッドを生成したとする。その結果、メモリがなくなった時には、他のアプリケーションは作業を続行できない状態になる。いわゆるDoS（サービス拒否）攻撃と同じだ。それでも、利用者が問題のあるタスクを終了したりすれば復帰は可能だが、律儀に自らのリソースを開放する設計のアプリケーションなどないだろう。そこでカーネルが動作を続けることは、「突然ハングするよりはマシ」程度のことでしかない。
Prexもカーネル内部にリソースのリミットを設けて、POSIXのsetrlimit()と同じようなインターフェイスを提供する予定。各リソースのリミットはタスク毎に保持し、タスク数のリミットはシステムに一つ保持する。各リミットのデフォルト値は、プラットフォーム毎に調整可能とする。
