例によって、カーネルメイリングリストにも振っておきます :-)。
>> On Thu, 01 Jun 1995 23:32:00 +0900, 真鍋 裕一 <NBG02534@niftyserve.or.jp> said:
>> うーん、こういうふうに実装してしまうと、デメリットの方が大きい
>> と考えてしまうのはおかしいでしょうか?
> メリット/デメリットのどちらが多いかは、私には判断しかねます。出来るだけ制
> 約が無いほうが望ましいのですが、制約によって実装が簡単になると言うのであれば
> 、あとはトレードオフで決める事になると思います。
> 実際問題として、1プロセス当たりでサブタスクが幾つまで使用できれば適当なの
> かが判りません。おおよその値が決められるものでしたら、それを制限とすれば良い
> と思います。しかし、用途によって望ましいサブタスクの数に幅があるばあい、3B
> の様にサブタスクを7として決め打ちするのは、デメリットの方が大きいと思います
> 。
なるほど、そうですね。
私も、アプリケーションに、不要な制限を加えるのはやめた方がいいと思いま
す。
> この問題は、プロセスのスタックエリアの大きさとも関連するかと思います。コー
> ド領域/データ領域はサブタスク間で共有しますが、スタックはサブタスク毎に割り
> 当てる必要があります。3Bの場合は、サブタスク一つ当たりのスタックサイズを最
> 大で512Kバイトに制限し、4Mバイトのスタック領域を8等分して使用するとの
> 事です。
そういえば、昔 Mach もこういう実装をしていると聞いて、あるタスクがスタッ
クをどんどん伸ばしていって、他のタスクのスタックを食いつぶしていくのを
どうやって防ぐのかについて疑問を抱いたことがありました。
# 結局、どうなっているのかわかりませんでしたが。。。
3B では、スタックの侵害をどうやって防いでいるのでしょう?
ひょっとして、その辺は何も考えていないとか? あるいは、512K バイトの領
域ごとにマッピングしていない仮想ページを 1 ページ置いておいて、侵害を
防いでいるのかもしれませんね。
-- 内藤隆一 (ggc00661@niftyserve.or.jp/night@bfree.rim.or.jp)