[ruby-list:14086] Re: Thread GC (Re: Re: timer)

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

On Tue, 27 Apr 1999 22:13:14 +0900
[e-mail] (YANAGAWA Kazuhisa) wrote:

> 気づかれないようにそっとやるんならデバッガと同じですね．

その「やる」ってのは、ナニをやるかってーと
結局、相手の、状態を書き換えるか特定ルーチンを起動するか
どっちかでしかないんですよね…

こーいう「普通の(^^;」プログラムを作る場合、既にわれわれは
oopというヤリカタを知っているわけで、やっぱり有効活用
したいよね、と思うのです。

> # 「哲学なんてない，だってその方が便利だし」で十分ですけど．個人的には．

「状態」が暗黙の了解でしかない旧来手法は、「便利じゃない」と
感じています(^^;

> 自分家の郵便受けに届こうが，郵便局の私書箱に届こうが，わたし宛の手紙で

ほら、届ける先はいずれも変数(器)じゃないですか(^^;

結局、ルーチンと変数が値をやり取りする、というモデルは
どこまで行っても(ちゅーりんぐましん、ってんでしょか、こーゆーのを？)
かわるわけじゃない。本当に「ルーチンと変数が」であって「ルーチンと
ルーチンが」ないしは「変数と変数が」値をやり取りすることは金輪際ない、と。

そのまんま、おぶじぇくと、だと思うんですよねーこーゆーの。

> > 自分(のプロセス)になげられたメッセージなのに、別プロセスを生成して
> # ここでいっているプロセスはプロセス代数なんかでいうプロセスで，要する
> # に能動主体というだけの意味です．スレッドといってもいいし，もっと軽い
> # 物でも構わない．逆に UNIX プロセスでやると重すぎて話にならない (^^;

勿論(^^;
とりあえずfork()ってインド人もビックリだなーとか思うです。

結局、おぶじぇくと、だよなーと思うんですね、そーゆーモデルも。

従来はコンテキストとかハンドルとかIDとかいう言い回しで誤魔化していた
(そうでないものは「ルーチン」と呼ばれていましたから(^^;;;)けど
結局それってオブジェクトと本質同じじゃん、ならば折角だから赤^H
既に知られたそのヤリカタをベースにしたほうが、楽じゃん？と。

> > 安全じゃないってのはつまり奇麗でもないということで(^^;
> わたしがいってたのは「どこの誰ともしらない人が『リセット』ってメッセー
> ジ送って来たけどどうしよう」っていう話ですのであんまり関係ないと思いま

5W1Hに対して許可を与えるかどうかをナンラカの手段(^^;で制御すれば
いいだけでは…

仕事で使ってる(作ってる)あるシステムには、
「誰(ユーザーオブジェクト)が」
「どのクラスorオブジェクトに」
「なんていうメッセージ(メッセージオブジェクトのクラス)を」
「どーゆー条件が成り立つ時に(条件オブジェクト)」
投げて受け付けられるか？を制御する、ルールオブジェクト(うげ)がありますー

まぁオブジェクトかどうかはさておき、セキュリティはまた別問題じゃ
ないかなーと思います。

> そこはそれ，クライアントはメッセージの送り先をしっているべきなのです．
> それがわからないのなら，システム全体として両方のサーバは同期していてよ
> り利用しやすい方にメッセージが届き，結果が得られるようになっているべき

え？！そんな気持ち悪い。なにしに複数サーバーなんです？
「区別」する意味がないなら「複数」あってもしょーがない(^^;
それぞれ違う結果を求めているからこその複数なわけで。

「ウチは違うでぇ。別の窓口いってや」って答えるかどうかは、またちょっと
微妙に違う問題というか、上位層の問題というか…。つまり、まず「ウチ」
という概念があるかどうかから話が始まるんではないかなあ。

＃行き先振り分けオブジェクトを用意するほうが幸せだな。

> # なんかこう，理想論ばっかり (^^;

どうせ理想なら、より「使いやすい」ほうの理想がいいなぁ(^^;

> 実際にサーバ/クライアントシステムとして考えると「クライアントがメッ
> セージの送り先をしっているべき」というのでは使いにくくなります．そのた
> め実際にはサービス名とメッセージの送り先の表が用意されていて，クライ
> アントはこれを見るという考え方があります．

あ。そういや、サーバーだけでなくクライアントも複数になることが有りますね(^^;
つーか3層4層とやらのシステムになれば、それらの関係が更に複雑になる。

最初の一発(こーゆーのをログインってのかな)は無論知りようがないんで
ナンラカの手段(^^;で知る事になりますが、その次はいったん接続した相手を
クライアントが覚えればいいだけっすよね。ログアウトとはその記憶を忘却する
こと。ログインはユーザーオブジェクトがサーバーオブジェクトを記憶すること。

状態を「複数区別して」覚える事に意義があるケースは、
すべからくオブジェクトと考えるのが「向いている」と思います。

> でもその表に最初にアクセスする時にはどうするのかというと，結局「しった
> 場所にあると仮定する」という方向から抜け出せなかったり．

まぁその辺はシングルトンだかテンプレートだかプロトタイプだか…
＃トコロテンだかテンプラだか風呂吹き大根だか…あれれ？？