Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: "Mike Schilling" Newsgroups: comp.lang.java.programmer Subject: Proposed new Java feature Date: Sat, 26 May 2012 16:11:13 -0700 Organization: A noiseless patient Spider Lines: 23 Message-ID: Injection-Date: Sat, 26 May 2012 23:11:03 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="MPGXQTXsvPvqVKHgwEYAAw"; logging-data="31720"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+llV8JlRyvqPjvHop5/BFjMtACTxyFEAY=" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-RFC2646: Format=Flowed; Original X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 Cancel-Lock: sha1:kdSc/6zG9MMhLkdkHNzoTJKkaHQ= X-Priority: 3 X-MSMail-Priority: Normal Xref: csiph.com comp.lang.java.programmer:14824 First a few observations: 1. ThreadLocals may be, in general, an abomination, but there are situation where they're the least of evils. And if you're building a framework in which third-party code runs (e.g. a webserver), there's no way to disallow their use. 2. ThreadLocals interact badly with ThreadPools, because the ThreadLocals keep their value when the tyhread is put back into the pool. This can lead to leaks and even potential security issues. 3. The current implementation of ThreadLocal is this: each thread contains a map from the ThreadLocal instance to its value for that thread. (This is slightly less intiutive than giving a ThreadLocal instance a map from Thread to value, but has the advantage that the map, which is only used within one thread, needn't be synchronized.) Proposed feature: a static method on Thread that clears all ThreadLocals for the current thread. By 3 it's trivial to implement. By 1 and 2 it's needed. And ThreadPool implementations can simply call it directly before putting the Thread back into the pool.