From: Nakamura Akifumi <BXQ04723@...>
Date: 2000-12-02T20:04:15+09:00
Subject: [ruby-list:26262] Re: fork problem?


お世話になっております。 A.中村です。

On Sat, 2 Dec 2000 15:44:47 +0900
Masato KIYAMA <masato@csys.ce.hiroshima-cu.ac.jp> wrote:

> forkって，UNIXではもっとも重要な概念だと思うんですよ．
> 単純さを指向した，UNIXでは．

unix(の枠組みの範囲内)では、そうなのでしょうね。
そもそもfork()から話が始まっているOSなわけですよね。
fork()より単純なモノを提供することはunixには出来ないのだろうなと。

俺にはfork()はトリッキーな発想だなと思えるんですけどね。

> で，UNIX文化を継承してるRubyでは，それを使えて当り前というか．．．

「なぜ言語にブリッジを用意するのか？」「そこにNativeAPIがあるからだ」
という戦略は、常に有用とは言いきれないような気もします。

うーん。unix文化継承か。結局そこに行きついちゃいますね。
require 'unix' …ぼそぼそ…

> あと，プロセスって，スケジューリングの単位，
> 保護の単位，資源割り当ての単位なんですよね．
> スレッドは，スケジューリングの単位だけです．

あ。それはありますね。unixには仕方ない選択肢ですね。
全部の単位がプロセスに集中してる。
Lensっていう言語の能書きをもじれば、
「プロセスは働きすぎだ」って感じでしょうか。

OmicronってOSの話を最近聞きました。
保護単位と実行単位は別になってるそうです。
なるほど、と思いました。

> あと，今のforkって，copy-on-writeなので
> 丸ごとコピってるわけではないです．

ええ。そうなんだそうですね。BSDマガジンで(^^;読みました。
それを読んで尚更、実装依存な話だなーと思いました。
「一番パフォーマンスが良いから皆使う」っていうか。
＃皆使うから性能向上が図られた、とも言うんだろうけど。

> initプロセスがすべてのプロセスの親で，木構造になってるのは
> すごく，きれいだって思ってました．

「何が」木構造を成しているか、が気になっています。
よりによって実行コンテキストまでコピるこたぁないだろ？と
思ったです。データやリソースまでなら判るんですけどね。