Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: "Mike Schilling" Newsgroups: comp.lang.java.programmer Subject: Re: Proposed new Java feature Date: Sun, 27 May 2012 21:43:40 -0700 Organization: A noiseless patient Spider Lines: 74 Message-ID: References: <8Euwr.47425$On2.20024@newsfe16.iad> Injection-Date: Mon, 28 May 2012 04:43:44 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="iYy4J5Lif+rA7f5yQr5JWQ"; logging-data="5330"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+snPH3GvFRH/dpZ+QztJC88sSgB8pQRqI=" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-RFC2646: Format=Flowed; Response X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 Cancel-Lock: sha1:B6prZwHpCnNWM6gZEV7eKi0UUrs= X-Priority: 3 X-MSMail-Priority: Normal Xref: csiph.com comp.lang.java.programmer:14851 Eric Sosman wrote: > 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. Note that it makes your objections moot. There's no way to enforce that the called code be "correct", and there is no invoker to worry about.