This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: natThread.cc: Destroy join sync objects in finalizer


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/





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]