[#28337] constant look up order in CVS HEAD — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

15 messages 2006/02/18
[#28338] Re: constant look up order in CVS HEAD — Tanaka Akira <akr@...17n.org> 2006/02/19

In article <1140229116.805371.31930.nullmailer@x31.priv.netlab.jp>,

[#28341] Re: constant look up order in CVS HEAD — GOTOU Yuuzou <gotoyuzo@...> 2006/02/19

In message <87lkw8xfay.fsf@m17n.org>,

[#28342] Re: constant look up order in CVS HEAD — Yukihiro Matsumoto <matz@...> 2006/02/19

まつもと ゆきひろです

[ruby-dev:28322] Re: SEGV with zlib

From: Tanaka Akira <akr@...17n.org>
Date: 2006-02-08 18:58:02 UTC
List: ruby-dev #28322
In article <1139389846.836984.23970.nullmailer@x31.priv.netlab.jp>,
  Yukihiro Matsumoto <matz@ruby-lang.org> writes:

> Javaのfinalizerにも同様の問題があって(というかJavaレベルで直
> 接書けるからよりタチが悪い)、それはいろいろ苦労して対応して
> いたような。
>
> 今思いついたのですが、T_DATA finalizerの呼び出しをmarkと
> sweepの間に持っていって、finalizeするT_DATAオブジェクトに対
> してマーク関数を呼び出すことで、対応できないことはないですね。
> でも、GCごとに全オブジェクトのスキャンが一回増えるのでうれし
> くはないですけど。

GzipWriter がつながっている時には、根元から実際の IO に向かっ
て順番に finalize していく必要があります。

そうではない順に finalize してしまうと、finalize で書き込も
うとした時には書き込み先がすでに finalize 済み (close 済み)
で書き込めないことになります。

なので、オブジェクトが生きているというだけでは十分ではありま
せん。もちろんオブジェクトが生きているということ自体は重要で
すが、順序を制御する仕掛けも必要になります。

やるとしたら IO や GzipWriter に参照元を登録する機能をつけて、
finalize 時にはまず参照元を finalize するのだろうか、と思っ
ています。

なお、Java でも finalizer の呼び出しの順番は不定なので、順序
を制御する場合には自前でやらないといけないと思いますが、どう
してんのかな。
-- 
[田中 哲][たなか あきら][Tanaka Akira]

In This Thread