[#1219] ruby animal — OZAWA Sakuro <crouton@...>

小澤さく@塩尻Internetです.

18 messages 1996/12/09

[#1256] ruby 0.99.4-961212 available — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです.

21 messages 1996/12/12
[#1257] Re: ruby 0.99.4-961212 available — Yasuo OHBA <jammy@...> 1996/12/12

大庭@SHLJapanです.

[#1258] Re: ruby 0.99.4-961212 available — matz@... (Yukihiro Matsumoto) 1996/12/12

まつもと ゆきひろです.

[#1259] Re: ruby 0.99.4-961212 available — WATANABE Hirofumi <watanabe@...> 1996/12/12

わたなべです.

[#1261] Re: ruby 0.99.4-961212 available — matz@... (Yukihiro Matsumoto) 1996/12/12

まつもと ゆきひろです.

[#1290] ruby 0.99.4-961217 will be available — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです.

32 messages 1996/12/17
[#1300] Re: ruby 0.99.4-961217 will be available — sinara@... 1996/12/17

原です。

[#1305] Re: ruby 0.99.4-961217 will be available — matz@... (Yukihiro Matsumoto) 1996/12/17

まつもと ゆきひろです.

[#1308] Re: ruby 0.99.4-961217 will be available — gougi@... (Shigeru Gougi) 1996/12/17

ごうぎ@TCIです。

[#1341] Re: ruby 0.99.4-961217 will be available — matz@... (Yukihiro Matsumoto) 1996/12/18

まつもと ゆきひろです.

[#1342] Re: ruby 0.99.4-961217 will be available — sinara@... 1996/12/18

原です。

[#1345] [BUG?] access string out of range — sinara@... 1996/12/18

原です。

[#1330] Re: Rational and Complex — Shin-ichiro Hara <sinara@...>

原です。

30 messages 1996/12/17
[#1335] Re: Rational and Complex — sinara@... 1996/12/18

原です。

[#1359] Re: Rational and Complex 1996/12/18

けいじゅ@SHLジャパンです.

[#1423] 配列への grep — (Dezawa Shin-ichiro) <dezawa@...>

出沢です

14 messages 1996/12/23

[#1469] wish ... — Noritugu Nakamura <nnakamur@...>

25 messages 1996/12/24
[#1470] Re: wish ... — matz@... (Yukihiro Matsumoto) 1996/12/24

まつもと ゆきひろです.

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

From:
Date: 1996-12-19 06:57:56 UTC
List: ruby-list #1379
けいじゅ@SHLジャパンです. 

In [ruby-list :01362 ] the message: "[ruby-list:1362] Re: [Dist]
distributed ruby ", on Dec/18 16:27(JST) matz@caelum.co.jp (Yukihiro
Matsumoto) writes:

>とりあえず簡単に.

確かに....

>|[1]. ビルトインクラスのビルトインメソッドが引数をとる場合

>うーん,ちょっと考えて思い付くのは
>
>  * ビルトインクラスはマイグレートする
>  * ビルトインクラスのメソッドを片端から再定義する
>
>くらいですかね.特に問題になりそうなビルトインクラスは文字列,
>配列,連想配列くらいですから,上の二つの組合せで解決できない
>かなあ.

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

そこで次の案はどうでしょう?

1. 文字列を引数にとるメソッドは, 文字列でなければ to_s を実行するよう
   になっている. 
2. 配列を引数にとるメソッドは, 配列でなければ to_a を実行するよう
   になっている. 
3. 引数となるオブジェクトに対しては, 副作用がない.

全て(ほとんど)のビルトインメソッドが上記のことを保証していれば, この問
題は解決するのでは? ないかと思うのですがいかがでしょう??

>|[2]. マイグレーション
>
>これは原理的に不可能だと思います(オープンしたファイルをマイ
>グレートするなんて普通のOSではちょっと無理そうでしょ).

たしかにそうですね. ただ, マイグレーションは今のところ自動的に行なうつ
もりはないので, 少しぐらいは制限があっても良いと思っています. 

>ただ
>し,類似のものは可能だと思います.クラス名なら向こう側の同名
>のクラスにするとかなんとか.

うーん. 動作が... でも, 同じクラスがあって動作が違っていても困るしなあ...
マイグレートする場合はそのクラスがローカル側になくてはいけないことにし
よう...

クラスサーバとかメソッドサーバの機能はネイムサーバと同じで別に検討する
ことにします.

>|[3]. 即値
>はいそうです.

[4]. GC
>                                真の問題はGCか?

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

今考えているのは,

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

とこのぐらいのことを考えています.

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

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

__
..........................................石塚 圭樹@SHLジャパン(株)...
------------->アドレス変わりました!! e-mail: keiju@shljapan.co.jp <----

In This Thread