Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #14838

Re: Proposed new Java feature

From Eric Sosman <esosman@ieee-dot-org.invalid>
Newsgroups comp.lang.java.programmer
Subject Re: Proposed new Java feature
Date 2012-05-27 15:30 -0400
Organization A noiseless patient Spider
Message-ID <jptvdf$1s5$1@dont-email.me> (permalink)
References <jprnu7$uv8$1@dont-email.me> <jptkmp$vbg$1@dont-email.me> <jptq42$1jo$1@dont-email.me> <8Euwr.47425$On2.20024@newsfe16.iad> <jpttrh$nqe$1@dont-email.me>

Show all headers | View raw


On 5/27/2012 3:04 PM, Mike Schilling wrote:
> "Daniel Pitts"<newsgroup.nospam@virtualinfinity.net>  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.
>>>>
>>>> <http://weblogs.java.net/blog/jjviana/archive/2010/06/10/threadlocal-thread-pool-bad-idea-or-dealing-apparent-glassfish-memor>
>>>>
>>>> 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?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-26 16:11 -0700
  Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-27 13:32 +0200
    Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 11:14 -0700
      Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 12:13 +0200
      Re: Proposed new Java feature v_borchert@despammed.com (Volker Borchert) - 2012-06-04 20:16 +0000
  Re: Proposed new Java feature markspace <-@.> - 2012-05-27 09:28 -0700
    Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 11:00 -0700
      Re: Proposed new Java feature Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-27 11:46 -0700
        Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 12:04 -0700
          Re: Proposed new Java feature Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-27 15:30 -0400
            Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 12:59 -0700
              Re: Proposed new Java feature Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-27 17:51 -0400
                Re: Proposed new Java feature markspace <-@.> - 2012-05-27 15:20 -0700
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 12:13 +0200
                Re: Proposed new Java feature markspace <-@.> - 2012-05-28 08:28 -0700
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 19:29 +0200
                Re: Proposed new Java feature markspace <-@.> - 2012-05-28 12:16 -0700
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 22:58 +0200
                Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-28 21:40 -0700
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-29 22:52 +0200
                Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-29 18:53 -0700
                Re: Proposed new Java feature Tom Anderson <twic@urchin.earth.li> - 2012-05-27 23:27 +0100
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 12:22 +0200
                Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 21:43 -0700
                Re: Proposed new Java feature Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-05-29 14:32 +0000
  Re: Proposed new Java feature Tom Anderson <twic@urchin.earth.li> - 2012-05-27 18:43 +0100
  Re: Proposed new Java feature Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-06-02 12:41 -0700
    Re: Proposed new Java feature markspace <-@.> - 2012-06-02 15:55 -0700

csiph-web