Re: Proposed new Java feature
On Sun, 27 May 2012, Eric Sosman wrote:
On 5/27/2012 3:59 PM, Mike Schilling wrote:
"Eric Sosman"<esosman@ieee-dot-org.invalid> wrote in message
news:jptvdf$1s5$1@dont-email.me...
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.
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.
It seems to me that you did not.
If you think of anything new to add, pray do so.
Mike added this pithy statement of the goal:
Or, to say it another way, when getting a Thread from a ThreadPool, it
should be completely indistinguishable whether it's a recycled or
brand-new thread.
At the moment, it is *not* possible to achieve that, because ThreadLocals
will survive recycling.
One way of looking at a thread pool is that it provides a supply of fresh
short-lived virtual threads, implemented on top of long-lived real
threads. Every time we take a thread out of the pool, we want it to appear
brand-new. Deleting all ThreadLocals when a real thread is recycled is not
"extremely dangerous", because at that moment, the *virtual* thread is
dying, and a new one is being created; that makes it an entirely
appropriate thing to do.
It is certainly true that it is "only a crutch for not doing the right
thing to begin with", but the sad fact is that programmers persist in not
doing the right thing to begin with, and it is useful for framework
writers to be able to limit the damage they can cause.
tom
--
Mathematics is the door and the key to the sciences. -- Roger Bacon