This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [PATCH]: natThread.cc: Destroy join sync objects in finalizer
- From: Mohan Embar <gnustuff at thisiscool dot com>
- To: tromey at redhat dot com, Bryce McKinlay <mckinlay at redhat dot com>
- Cc: Hans Boehm <Hans dot Boehm at hp dot com>, GCJ Patches <java-patches at gcc dot gnu dot org>
- Date: Sun, 12 Sep 2004 17:46:01 -0500
- Subject: Re: [PATCH]: natThread.cc: Destroy join sync objects in finalizer
- Reply-to: gnustuff at thisiscool dot com
Hi People,
>>We could also just clean up the native state when the thread dies.
>>That is probably even better.
>Yes, this would be cleaner, but we'd need to be careful that
>Thread.join() etc don't try to access the native state after it has been
>freed. To avoid race problems here we could perhaps register the
>finializer on the native state (natThread) itself rather than the
>java.lang.Thread, and atomically release it (set "thread->nt" to null)
>when the thread dies.
Believe it or not, my initial iteration attempted to clean up the native
state when the thread died, but:
- I didn't know what to synchronize on.
- I figured it would require synchronizing on something every time we
needed to access the native state, which would unnecessary penalize
everyone because of the fringe case of troublemakers trying to
resurrect a thread.
Recall that the JLS states that Object.finalize() will only ever be called
once for an instance:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#finalize()
If someone decides to resurrect a thread this way instead of creating a
thread pool, they're going to run into problems if they hope that they can rely
on finalize() being called again the next time they feel like resurrecting a
thread this way....
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/