[ruby-list:1381] Re: [Dist] distributed ruby

まつもと ゆきひろです．

In message "[ruby-list:1379] Re: [Dist] distributed ruby"
    on 96/12/19, 石塚圭樹 <[e-mail]> writes:
|
|けいじゅ＠SHLジャパンです. 

|マイグレーションは, オブジェクトのアイデンティティが維持できないのでプ
|ログラムの動作が異なってくるというのが気になります. bignumぐらいならマ
|イグレートしても良いですが, 文字列になるとちょっと躊躇しますし, 配列と
|なると... 問題外ですね... あと, 任意のビルトインクラスはマイグレーショ
|ン可能でないですしね.

まず，immutableなものはマイグレートしても問題ないですよね．
ですから，Float, Bignum, RegexpはOKです．問題になるのは
String, Array, Hash, Struct, Fileですね．あとDataとかいうの
もありますね．これらのうちFile, Dataはどうやってもマイグレー
トできませんね．それとClass, Moduleは準mutableという感じでこ
れもマイグレートできません．

|そこで次の案はどうでしょう?
|
|1. 文字列を引数にとるメソッドは, 文字列でなければ to_s を実行するよう
|   になっている. 
|2. 配列を引数にとるメソッドは, 配列でなければ to_a を実行するよう
|   になっている. 
|3. 引数となるオブジェクトに対しては, 副作用がない.
|
|全て(ほとんど)のビルトインメソッドが上記のことを保証していれば, この問
|題は解決するのでは? ないかと思うのですがいかがでしょう??

to_sやto_aは強力すぎて現在一応行っている動的な型チェックを無
効にしてしまう危険がありますので，若干抵抗があります．絶対ダ
メと言うほどではないので説得してください．

最後のものは現在でもそうなっているような気がしますが，全部の
メソッドを確認してみないと保証はできませんね．だれか確認して
くださいませんか?

|>                                真の問題はGCか?
|
|シグネチャに入れないように. 完全な分散GCは難しいですよね. あまり複雑な
|ものはrubyにふさわしくないし...

松本のあれはシグナチャではないんじゃないだろうか…．

|今考えているのは,
|
|1. proxyを供給している間は, GCされないようにする(ankerd). リファレンス
|   カウントを1+.
|2. コネクションが切れたら対応する元オブジェクトのリファレンスカウント
|   を1-.
|3. proxyがGCの対象になったら, 元オブジェクトのリファレンスカウントを
|   1-.
|4. リファレンスカウントが0になったらGCの対象とする(deankerd)
|5. それでも, ループが発生するとリファレンスカウントは0にならないので, 
|   いらなくなったproxyは明示的にdeankerする.  
|
|とこのぐらいのことを考えています.

anchorですね．分散リファレンスカウントはループが恐いですね．
いやあ，苦労しました(なにかつらい想い出があるらしい)．

|そこでリクエスト!! あるオブジェクトがGCの対象になった時にあるフック関
|数が呼び出されるようにしてください.

ええと，そうするとそのメソッドをrubyで書けるんですか?

その場合，ちょっと考えただけでも以下の問題が考えられます．

  * そのメソッド実行中はメモリがタイトであることが考えられま
    す(そもそもGC実行中なので)，実行中にオブジェクトを生成し
    ようとしてメモリが足りない場合にはあきらめる?

  * そのメソッド実行中にたとえばselfを大域変数に代入したりす
    るなど，「死んでいる」はずのオブジェクトを「生かす」こと
    ができたりします．これにどう対応する?

Cのデータ構造を追加する時には「こういう問題があるけど気をつ
けて使ってね」とfinalizerを用意していますが，一般のオブジェ
クトとなるとちょっと恐いですね．

以上の様な問題に対応するアイディアがあれば，採用します．

|まだまだ問題があるのであった...

でしょうね．
                                まつもと ゆきひろ /:|)