From: matz@... (Yukihiro Matsumoto) Date: 1998-10-16T14:47:23+09:00 Subject: [ruby-list:10145] Re: デストラクタ (?) まつもと ゆきひろです In message "[ruby-list:10072] Re: デストラクタ (?)" on 98/10/14, Takashi Nakai writes: |最近のC++の（たぶんPerlでも）傾向としては、コンストラク |ター＆デストラクターで（メモリーおよびその他の）資源の管 |理を行うようになってきているようです。 rubyでもそうです． |と言うのは、こういったことに対応するためだとは思うのです |が、世の中にはメインメモリーとファイル以外の（そのユーザー |特有の）資源を管理したい用途はあると思います。 | |その時にGC発生条件を増やしていく訳にはいかないと思います。 まず，発生条件としては資源の不足が検出できるなら，rubyのレベ ルで明示的にGCをスタートさせれば良いと思います．つまり，その 時点で GC.start ですね． で，デストラクタですが，rubyレベルでは不要である，あるいは不 要であるように設計すべきだと考えています． しかし，Cレベルでは当然発生しますので，それはData_Wrap_Struct のfree引数にデストラクタ(要するに解放関数)を指定することで対 応するべきだと考えています． |特に、組み込み系／リアルタイム系のシステムではメモリーに限 |らず資源はケチケチなんですよね〜（ruby を組み込む余裕がない |ほど．．．） |そういった時に、参照カウント方式のメモリー管理って結構有用 |なんですよ。 Pythonの作者Guido氏はかつてそのような発言をしてPythonがリファ レンスカウント方式を採用している理由を述べていました．が， Rubyは他の点でもメモリを喰うので，そこだけ有用にしてもしょう がない気がします．実装がかなり大名なので． リファレンスカウント方式の欠点のうち， | ・循環データを削除できない（←こいつは痛い！） | ・全体に処理が重くなる。 | ・ruby自体、および拡張モジュールを書く場合の手間が増える 最初のものと最後のものは私にとって受け入れられませんでした． もしかすると，将来組込み系でも使えるPico Ruby処理系なんての が出てきて，そこではまた違うポリシーを採用するかも知れません が，現行のrubyのGCは，そのような分野もカバーするオールラウン ドプレーヤーであることよりも，現状のような「多くの場合に思い きり楽が出来る」ということの方が重要だと思います． |（マーク・スイープ方式と比べた場合の）参照カウント方式の利点 | | ・開放タイミングが予測可能。 | ・（開放タイミングに関連して）処理時間の予測が可能 | ・（開放タイミングに関連して）資源の早期の開放が可能 | ・ある日突然、GCが走って中断することがない | |と言ったところでしょうか、 | |リアルタイム処理の定義は、「処理時間が早い」ことではなくて、 |「確実にある処理時間内に処理が終了する」ですので、参照カウン |ト方式が向いています。 良くそういうのは聞きますね．でも，「普通の」リファレンスカウ ントの実装ではカウントがゼロになったタイミングで再帰的に解放 が発生してしまい，mark and sweepほどでないにしても，処理時間 の予想は困難のように思うんですが，どうなんでしょう． # hard real time GC なんて論文も見たな，reference countでは # なかったと思うけど． さらに，特にPythonに見られるんですが． f = open(path, mode) #... f = None でfに代入した瞬間にcloseされることを期待するようなコーディン グを助長するのは，ダメとは言わないものの心苦しいです． まつもと ゆきひろ /:|)