Boehm, Hans wrote:
> Blocking on IO indeed seems dubious. But finalizers almost
> always need to acquire at least one lock.
Agreed, but outside of the lock needed to protect the finalizable
resource it's probably best to avoid taking other locks, because it is
very easy to introduce potential deadlocks that way.
> In the example in your blog, the finalize method should be
> synchronized (or start with synchronized(this) {} ) to
> guarantee reachability of the object while one of the other
> synchronized methods is running.
Huh? finalize calls the synchronized close method, so it doesn't need to
be synchronized.
> If you follow the (admittedly baroque) rules, there are safe ways to
> clean up Java resources with finalizers as well, though
> clearly not when timing matters.
>
> And you actually need to follow very similar rules for java.lang.ref.
Well at the very least the fact that you control the threading with a
reference queue makes things a little easier. For example, the I/O
blocking issue is not a problem if you can do it in your own thread.
Regards,
Jeroen
_______________________________________________
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
