In message <3724BC6A2B7.DBEF.anakamur / exa.i-tech.co.jp> anakamur / exa.i-tech.co.jp writes: > そのくせにどういうわけか、手続きのカタマリで作られた > 「アプリケーション」は、「存在する」かのように理解されて > いることが多いんですよね。たとえばプロセスIDとか(笑)。 それは，動いているプログラム == プロセスは実在の実体だからでしょう． PID はそのプロセスの識別子．コードではなくて，あくまで動いているプログ ラム． > ましてやプロセスIDめがけてシグナルを投げるなんて…くわばらくわばら。 > なんてーか溝めがけてシグナル投げてるかのようです。 いえ，これは川に何か投げ込んで流れを変えるという行為に.... 無理なたと えは苦しい．(^^; > プロセス間通信といっても、ほんとの意味でプロセス同士「が」 > 通信してるんでしょうか？ > 結局、プロセスと直接接するのは「状態」だと思うのですが… > 無論、状態が接するのはプロセス(手続き)。 あるプロセスが別のプロセスのメッセージ受け入れ口とされている所に何か データを書き込みました．....っていうのは「プロセス同士の通信」とは認め ていただけない? > 同期取るなら同期フラグが存在しますし、同期しないなら > どこかに書き捨てて(笑)置いた状態を他のプロセスが読むことでしょう。 > ＃…で、いいんですよね？ 共有メモリを利用すると，プロセス間通信は簡単に書けますね．一方「実装が どうであれ」モデルとしてメッセージパシングしか持っていない場合だってあ ります． > シグナルも似たようなものかな。ポーリングなら状態が介在しますし > 割り込みだったらそもそも新規手続きの起動なんで議論から離れるし。 ちなみにこっちは「プロセス間通信」というよりは，「オブジェクトはメッ セージを受け取り，必要に応じてスケジューリングを行ってから要求に答える メソッドを起動する」というモデルを杓子定規に適用した結果の話だったりし ます． オブジェクトの中にはメッセージを受け取るプロセスが常に存在し，そのオブ ジェクトのメールボックス（メッセージキュー）に届いたメッセージを適当に 取り出して，適当に処理させる．一度に一つずつ処理していってもいいし，問 題なさそうなら複数のプロセスを生成して一度に複数のメッセージを処理して もいい． # このモデルを杓子定規に適用し，その上で効率的な実装を目指したシステム # として Concurrent Smalltalk があったりするわけです．....他にもいろい # ろあるけど． シグナルは通常の要求よりも優先度が高いメッセージとしてモデリングできる， と． > ただ、ちょっと美しくはないですね。好きなメソッドをばりばり > 定義しまくってという感じには程遠いですから。 いや，だから適当な要求メッセージで初期化でも状態書き換えでもできるよう にしておけばいいんですよ．難点は安全性に問題がある事ぐらいです (^^; > 「今readonlyでソースをあけているviのインスタンスはドレ？」なんて > 問い合わせをしたいなーと思う瞬間が、あるのですよー いや，それはソースファイルの方が責任を持って一貫性の管理を行うべきなの でしょう．あるいはファイルシステムかな．粒度が細かい方が扱いやすくなる けど性能が出なくて大変． ....もっともソースやファイルシステムが「一貫性に問題が出る可能性あり」 というメッセージを返しても，vi やユーザが無視したらどうにもならんので すが． > プログラムといっても、正確にいえばプロセス(ID)、ですよね。 > ディスク上に存在する実行ファイルは、そういう意味ではオブジェクトじゃない。 > コンストラクタみたいなもんでしょうか。 テンプレートでしょう．せいぜい． > 「サーバー(に限らないが)インスタンスを複数立ち上げたらどうなる？」 > という問題だったりします。 共有資源の食い合いをしない限り何の問題もないような気がします.... > で、ちょっと突っ込んだ話になると、今度は「インスタンスを > 同時でなくて時間差で使ったらどうなる？」があります。 > これは永続オブジェクトの話に突入するネタでして…逃げろー(^^; これは，同じインスタンスを利用している以上，本来なら何の問題も起こらな い話だと思います．....本当に完全に理想的なモデルが実現されている場合は ですが (^^; 常に同じ方法で参照する事ができる，っていうのはもっとも基本 的な機能でしょう． > ＃classified object oriented ってなら、まだわかるのだが… > ＃プロトタイプ指向はどうするつもりなんだろ？ 委譲とか．併合とか． # delegation と concatenation．「後から拡張する」のはなんていったっけ # かな.... -- 柳川和久 @ 東大阪市 . 大阪府 April 26, 1999 Time and tide wait for no man.