Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Proposed new Java feature Date: Sun, 27 May 2012 17:51:57 -0400 Organization: A noiseless patient Spider Lines: 71 Message-ID: References: <8Euwr.47425$On2.20024@newsfe16.iad> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sun, 27 May 2012 21:52:03 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="03ebLEozl+tXCe7JS60Feg"; logging-data="20718"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+o+Wh5D+FIILnVr+o2ZeYz" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: Cancel-Lock: sha1:W8Kq/WhW9H5RAZmLWXp/SSCZrvs= Xref: csiph.com comp.lang.java.programmer:14840 On 5/27/2012 3:59 PM, Mike Schilling wrote: > "Eric Sosman" wrote in message > news:jptvdf$1s5$1@dont-email.me... >> On 5/27/2012 3:04 PM, Mike Schilling wrote: >>> "Daniel Pitts" wrote in message >>> news:8Euwr.47425$On2.20024@newsfe16.iad... >>>> On 5/27/12 11:00 AM, Mike Schilling wrote: >>>>> "markspace"<-@.> wrote in message news:jptkmp$vbg$1@dont-email.me... >>>>>> On 5/26/2012 4:11 PM, Mike Schilling wrote: >>>>>> >>>>>>> Proposed feature: a static method on Thread that clears all >>>>>>> ThreadLocals >>>>>>> for >>>>>>> the current thread. >>>>>>> >>>>>> >>>>>> >>>>>> I can see your points. However, I don't have any real experience with >>>>>> ThreadLocal, and when a neophyte agrees with your argument, that's a >>>>>> red >>>>>> flag. >>>>>> >>>>>> Here's a blog where someone seems to have the same issue as you. >>>>>> >>>>>> >>>>>> >>>>>> At the end of the comments, there's a suggestion to use >>>>>> ThreadLocal::remove(), with the implication that it allows the thread >>>>>> local variable to be garbage collection. Is there a reason that >>>>>> doesn't >>>>>> work for you? >>>>> >>>>> That acts on an individual ThreadLocal (and works quite well), but it >>>>> doens't allow removing all ThreadLocals that might have been >>>>> accumlated. >>>> You're basically saying "This type of resource can leak if not cleared >>>> appropriately, so there should be a 'Release all resources' method." >>>> >>>> When paraphrased that way, does that make it clearer why it isn't a good >>>> idea? It would be about the same as a "File.closeAll()" or a >>>> "Socket.closeAll()" call. Extremely dangerous and only a crutch for not >>>> doing the right thing to begin with. >>> >>> Or a "collect all unused memory" call . Clearly, that's a crutch for not >>> keeping track of memory allocation properly in the first place. And the >>> fact that files and sockets are closed when a process exits is yet >>> another >>> crutch. >> >> I'm with Daniel. Your code uses classes that you wrote, and >> classes you got from somewhere else -- Sioux Unusuals, perhaps. >> And if those classes use ThreadLocals for their own purposes, and >> you blithely destroy them all, what happens then? Or what about >> the class that invoked your code, passing an InheritableThreadLocal? >> Is it a good idea to change parts of your invoker's state that you >> don't understand, that you aren't even aware of? > > Consider the use case again. I understood it fine the first time around, thanks. If you think of anything new to add, pray do so. > [... reiteration of old material ...] I notice that you do not address any of the issues Daniel or I raised; you just repeat what you "want." I know three-year-olds who can do that, but I don't rush to grant their every whim. -- Eric Sosman esosman@ieee-dot-org.invalid