On Mon, 2006-02-06 at 01:06, Jason T. Greene wrote: > Actually the behavior you describe is the semantics of Thread.destroy() > if it were actually implemented. Thread.stop() just forces the targeted > thread to throw a ThreadDeath exception. This causes all finally blocks > to execute, and in fact if a thread were to catch ThreadDeath, it could > prevent the thread from dieing. This also causes all monitors that were > aquired by the thread to be released. So, herein lies the problem. Since > this exception can occur at any point, the object state of that thread > is potentially corrupt. > > So, if the thread does not share state with other threads, it is > actually quite safe. This is hardly the case though, and is a problem > for BasicThreadPool because we do not know what the task is actually > doing.
Thanks for the clarification. Re-reading this: http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html This says it is never safe. 2 examples: lock = lock(); // Thread death here is bad! try { ... } finally { lock.unlock(); } An attempt to fix it lock = null; try { lock = lock(); ... } finally { if (lock != null) lock.unlock(); } But it won't work, because this code is really: lock = null; try { lock(); // Thread death here is bad! lock = popResultFromThreadStack(); ... } finally { if (lock != null) lock.unlock(); } -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
