[ruby-list:26465] Re: fork problem?

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

On Fri, 8 Dec 2000 22:47:51 +0900
Kazuyuki Shudo <[e-mail]> wrote:

> OS とはこういうもの (fork() 他) だ、という
> 固定観念に縛られまいとする姿勢です。
> 今の商用 OS はどれも UNIX (*) の影響を非常に強く受けていますよね。

「まいとする姿勢」とまでは俺は言えてませんが、不勉強の(笑)自分の目
から見た「あたりまえ」が、unixのあたりまえと一致してないのは
確かであるようです。
windowsですら血液の1割くらいはunixのソレを引いている
ように見えますが、やっぱりしばしば違和感感じています。

> 数年前に、OS と全プロセスで単一の仮想メモリ空間を共有することで
> システムコールのオーバヘッドを減らして軽い OS を作るという

あ。Omicronがソレ(の一つ?)みたいです。
http://www.os-omicron.org/~takano/doc/index.html
Multicsについても少し書いてあるようです。

ところでコレって、システムコールのオーバーヘッド云々なのかなあ？
どちらかというと「まずデータ(の同値ではなく同一性)ありき」
を実現するためのアーキテクチャであるように読めました。

> と言いつつ、僕は割と…いやかなり？ UNIX 好きなんですが…

まぁ俺も、最高のモノでなければ「愛着」が持てないものだ、とは
言いませんです(^^;。俺とてポケビ万歳です。


> 「require 'unix'」は明らかにジョークでしょうけれど…
> プロセス, fork(), ファイルシステム, ネットワークインタフェース
> などの (?) UNIX 文化依存部を言語処理系から切り分けるなんてことは
> どだい無理だと思ってます。

いや、今回一連の俺文のアベレージ(笑)からいえば、
ジョークの部類ではないつもりでした。

無理なんですか？ANSI Cくらいには分離可能、つまり
機種依存は「ライブラリ」が持てば良いのではないかと
思っていたのですが？
ライブラリからの分離が無理っていうならまだわかるんですが
(それとてmoduleなりなんなり分離できようし)
言語そのものですか？うーん謎だ…
Rubyもfork()は使う一方でNativeThreadは使ってないわけで、
そういう意味での選択の自由度は有るのだと理解していたのですが。
IOとかだとread()とwrite()だけがまず有って、それに
機種依存な分をincludeすれば良いんだろうな、と…

それに、上記引用を「真に受け」ますと、それこそ
「じゃあjavaからfork()をどうやって切り離したの？」
という変な話にイっちゃうわけで…
＃どこが変かというと、「切り離したんじゃなくて最初から」。



ーーーーーーーーーーーーーー
ここ数日で考えた(考え直した)話を全部そのままリプライしたら
凄いことになるんで、ちょっと団子としてそえちゃいます。すんません。


[ruby-list:26257] (木山さん)
>initプロセスがすべてのプロセスの親で，木構造になってるのは
>すごく，きれいだって思ってました．

木構造については、木構造を木構造としてのみ使うなら
すっきりするのでしょうけど、なんというか見ていると
Compositeパターン以外のパターンをCompositeパターンで
エミュレートしてるみたいな感じがしました。

親子関係ってのは1つしか持てないわけですから、
いろんな「関係」を持ちたいと思ったら結構困るはずなんだけどなあ。
で、困らないための新しい戦略が、oopとかマルチスレッドとかで
あるはずなんだけどなあ…


[ruby-list:26272](やすださん)
>execしてもそのプロセスは親プロセスのデータを一部継承できるところが
>味噌だと理解していました。このような仕掛けのおかげで、
>プログラムの記述方法が結構汎用的になるのだと言われていました。

考えをまとめてみた(あまりまとまってもいないが)んですが、
結局それって、「口は一つしかない」という世界観の範囲内で汎用
になる、と言えるのではないでしょうか？
Compositeパターン(のみ)っぽく全てが親子の間だけでカタがつく世界。

で、オブジェクトやスレッドがいっぱいある世界になってくると
あっちとも繋がってこっちとも繋がってになるわけで、
親子だけを特別扱いしても得るところが(相対的に)減ってくる
のではないかな、と。


[ruby-list:26318](神戸さん)
>> うーん。forkを掴まえるためにはforkロープが必要だったのか…
>???  意味不明です。

unixの需要を満たすためにはunix的なヤリカタを供給する、
という、一種のトートロジーみたいな感じかなと思ったもので。
ひとの言葉を泥棒させて頂くなら、[ruby-list:26267]首藤さんの言葉が
一番ビンゴと思いました。

>「からっぽのプロセス」という方がよっぽど特殊でしょう。からっぽはどこか
>ら生まれてくるんでしょうか。からっぽってどこまでからっぽなんでしょう?
>どのユーザの権限で動いているという情報もないんでしょうか??

OSを、それらの情報を「親から継承」することでしか得られない
という仕様にする事は、どれくらい価値があることなんでしょう？

あと、機能分離して欲しいってのもあります。
データはコピるものとしても、せめてプログラムカウンタ(笑)とか
そもそも「今実行しているかどうか」というコト自体とかを
コピるのは止めて欲しかったというか。
尤もunixでは不可能なのかも知れませんが。
コンテキストとかをそれ以外のデータときっちり分ける手段が
ないosであるわけですよね結局？

Ruby原さん本の「プロセス間通信」のとこを読んで
ますますfork()とそれに絡む幾つかの事象が嫌になりました。
特に、pipeを親子で共有するあたり(p145 図2.5 パイプによる通信)、
生理的嫌悪っていうか。わざわざ水漏れ穴をあけたパイプに
ガムテープ貼って使うのか？と。
通信は通信でもあれは「他者と」通信する方法ではなくて
「自分の子分のみと」喋る方法っすよね。うーむ。


[ruby-list:26265](神戸さん)
>UNIXベースの何かを制御したいからこそ、UNIXのプロセス制御に関する部分を
>捨てられないのは当然で、必要な機能でしょう。

「捨てる」でふと気付いたんですが、結局必要な機能ってのは、
「自分」が「Ruby(つーか今走ってるスクリプト)のであることを捨てる」
機能ですよね。つまりexec()。

でも逆にいえば、exec()で「pidが維持される」ってのほうが
よっぽど気持ち悪いです。
同一インスタンスなのにClassが変わっても嬉しいの？
というあれです。(Rubyで充分お馴染みのネタですよね)

なんかunixって、processって概念を拡大解釈しまくってる感じ。


[ruby-list:26326](まつもとさん)
>>既にある
>おそらくはそのような「(OS部も含めて)境界のない世界」を考
>えていらっしゃるような気がします。

それもまた俺の理想の一つですが(^^;、今回は微妙に違う話だと思っています。
「プロセスが何でも持っている世界ではないのだが、
アクセス制限機能も捨てているわけではない」という世界。

少なくとも「言語がosを統べる」世界を俺は意図してはいません。今回は。
＃「外側」がどこまでを指しているのかは知りませんが。

あ。セキュリティがなくなるというのは何故ですか？
なくならない構造のOSが無理というわけでもないはず。

ところで今回の話を友人にしたところ、面白い答えが返ってきました。
曰く、既にある違う文化ってのは「Rubyの文化」なんじゃないの？と。
そういわれてみればそうだよな、というか、その解釈のほうが
問題(^^;をより良く表現してるよな、というか。
オブジェクト＆スレッドってのが既にプロセス＆fork()と
「馴染まない」ってのは、このスレッドの最初から出てきてる話。
[ruby-list:26165]まつもとさん：
>forkとthreadを混ぜるのはかなり問題の元です。



ーーーーーーーーーーーー

ところで、こういうことを書くと建設的と呼ばれてしまう
のかも知れませんが(笑)、

Thread#kill_on_fork?
あるいは
Thread#on_fork
って仕掛けを作ったら、
解決(unix世界前提での)にはならないんでしょうか?

Threadをnewしたプログラマが、そのthreadインスタンスに、
「forkで殺されて良いか?」ないしは「forkされたときに
やりたいことは何?」って質問に答える能力を
(特異メソッドとかで)与えれば
解決するのかなーと思ったのですが、駄目ですか?

というか、こういうやりかたで対処「できない」ような
問題だとしたら、そもそも避けて通るほうが似合いな問題
であるような気が。

＃逆にいえば無理を通せば道理が引っ込むわけで、
＃言語と切り離せないってのはそういう意味ですか？＞首藤さん