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

On Mon, 26 Apr 1999 21:49:06 +0900
kjana / os.xaxon.ne.jp (YANAGAWA Kazuhisa) wrote:

> それは,動いているプログラム == プロセスは実在の実体だからでしょう.
> PID はそのプロセスの識別子.コードではなくて,あくまで動いているプログ
> ラム.

PIDが「存在」する所までは、まぁいいです。「識別」できるのもまぁいいか。
でも、そのPID(=Process)に対して、破壊的な(笑)作用を外部から与えたり
そこまで言わずとも単に読むだけでも読んだり、するってのはナニゴトか?と
思いまして。たとえば、

> > ましてやプロセスIDめがけてシグナルを投げるなんて…くわばらくわばら。
> いえ,これは川に何か投げ込んで流れを変えるという行為に.... 無理なたと

これがソレですね(^^;

ちなみにここでは川モデルは使えないですよね。
プロセスのプログラムカウンタ(笑)は、一瞬で駆け抜けてしまいますから。
川みたいに「元の流れじゃないけど絶えない」ものとは違って。
高速道路の自動車のイメージのほうがまだ近いかな。
#電車は長いので却下(笑)

> あるプロセスが別のプロセスのメッセージ受け入れ口とされている所に何か
> データを書き込みました.....っていうのは「プロセス同士の通信」とは認め
> ていただけない?

認めてもいいですが、それこそ定義の問題なんですよね。
つまり、それってプロセスに変数(データを書く場所)が従属してるか
あるいはプロセスと無関係な所に変数があるか、どっちかっていうだけの
ことですから…

> 共有メモリを利用すると,プロセス間通信は簡単に書けますね.一方「実装が
> どうであれ」モデルとしてメッセージパシングしか持っていない場合だってあ
> ります.

メッセージの受け手は何だ?という話に、やっぱりなると思います。
実装レベルまで話を落とさなくても。

>しぐなる
> ちなみにこっちは「プロセス間通信」というよりは,「オブジェクトはメッ
> セージを受け取り,必要に応じてスケジューリングを行ってから要求に答える
> メソッドを起動する」というモデルを杓子定規に適用した結果の話だったりし

んですね。

> 取り出して,適当に処理させる.一度に一つずつ処理していってもいいし,問
> 題なさそうなら複数のプロセスを生成して一度に複数のメッセージを処理して
> もいい.

ありゃ?
自分(のプロセス)になげられたメッセージなのに、別プロセスを生成して
それを処理させちゃうんだ…
やっぱりPIDって意味を持ってないのかな(^^;

> > ただ、ちょっと美しくはないですね。好きなメソッドをばりばり
> > 定義しまくってという感じには程遠いですから。
> いや,だから適当な要求メッセージで初期化でも状態書き換えでもできるよう
> にしておけばいいんですよ.難点は安全性に問題がある事ぐらいです (^^;

安全じゃないってのはつまり奇麗でもないということで(^^;
好きなメソッドを好きに書けるってのはつまり、メソッド(名)を
識別することによって「安全」を得ているわけですよね。

#そういやBeOSのファイルシステムにゃ、好きなファイル属性を定義する
#という仕掛けがあるそうで…良き哉。

> > 「今readonlyでソースをあけているviのインスタンスはドレ?」なんて
> > 問い合わせをしたいなーと思う瞬間が、あるのですよー
> いや,それはソースファイルの方が責任を持って一貫性の管理を行うべきなの

あ、それもそうですね。まぁファイルとviインスタンスとの間の
Relationだという気もしないでもないですが。

まぁ現実的にはCheckIn/Outでも使うのが正しいでしょうね。
って、そのソースで作ってるモノ自体にその機能があるんで
使えればいいなあ…とか思ってたら、やっぱり新しい版で、自分自身を
作成&改造するときのソース自体を自分自身のODBで管理できるように
なってしまった(って新しいclassが出来たというだけのことですが)(^^;

> > ディスク上に存在する実行ファイルは、そういう意味ではオブジェクトじゃない。
> > コンストラクタみたいなもんでしょうか。
> テンプレートでしょう.せいぜい.

ふみ。雛形っすか。確かにクラスには至ってないなあ…

> > 「サーバー(に限らないが)インスタンスを複数立ち上げたらどうなる?」
> 共有資源の食い合いをしない限り何の問題もないような気がします....

識別しないとなんないっすよね。
俺(たとえば某クライアントインスタンス)は今、どっちのサーバー「に」
接続すりゃいいんだ?とかいう悩みがありそうです。

#「する」側としてしか考えないなら、あまりoopは役立たないような
#印象を受けています。「される」側を考えるとoop必須って感じ。