This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
RE: [cp-patches] [PATCH] Fix PR classpath/24086, PR classpath/24091, PR classpath/24104 et al. ...
- From: "Jeroen Frijters" <jeroen at sumatra dot nl>
- To: "Boehm, Hans" <hans dot boehm at hp dot com>,"David Daney" <ddaney at avtrex dot com>
- Cc: "Java Patch List" <java-patches at gcc dot gnu dot org>,"Classpath Patches" <classpath-patches at gnu dot org>
- Date: Thu, 13 Oct 2005 23:49:44 +0200
- Subject: RE: [cp-patches] [PATCH] Fix PR classpath/24086, PR classpath/24091, PR classpath/24104 et al. ...
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