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: "Boehm, Hans" <hans dot boehm at hp dot com>
- To: "Jeroen Frijters" <jeroen at sumatra dot nl>,"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 15:41:59 -0700
- Subject: RE: [cp-patches] [PATCH] Fix PR classpath/24086, PR classpath/24091, PR classpath/24104 et al. ...
> -----Original Message-----
> From: Jeroen Frijters
>
> > 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.
Right. I misread that.
>
> > 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.
>
I agree. It makes this sort of thing easier, and it partially dodges
some of the finalizer ordering issues, at the expense of often needing a
new thread to process the queue. It doesn't help with the "premature"
finalization issue.
Hans