Path: csiph.com!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Robert Klemme <shortcutter@googlemail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Proposed new Java feature
Date: Mon, 28 May 2012 19:29:08 +0200
Lines: 99
Message-ID: <a2hqv5F695U1@mid.individual.net>
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> <jptvdf$1s5$1@dont-email.me> <jpu11t$c79$1@dont-email.me> <jpu7m3$k7e$1@dont-email.me> <jpu9aj$t3p$1@dont-email.me> <a2h1djFoq2U2@mid.individual.net> <jq05ij$kt9$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net iKCh3HO5ygpVdJPwNNNjPw9mdg4hdjeYD9lrDvq0ldl478xgWY51fr0HZooMPKjjE=
Cancel-Lock: sha1:W2Jyuw81bCMpkVfPli//0FBdJsU=
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
In-Reply-To: <jq05ij$kt9$1@dont-email.me>
Xref: csiph.com comp.lang.java.programmer:14868

On 05/28/2012 05:28 PM, markspace wrote:
> On 5/28/2012 3:13 AM, Robert Klemme wrote:
>> How can you know if you did not create the thread?
>
> But we are creating the thread. It's part of a thread pool for general
> use. That's his use case; it's the fundamental crux of his request.

Maybe there is a misunderstanding: I read your statement to mean that 
"Sioux Unusual class" assumes the thread to be dead while it was created 
by someone else (presumably the thread pool).  So it cannot know 
anything about thread creation and dead because it does not have any 
control over the thread's lifetime.

> I can think of a few scenarios where it would be useful to use both
> thread locals and a thread pool, so while maybe "dangerous" it's still
> something we should investigate properly.

It's certainly a useful idiom: the thread pool saves the overhead of 
creating and destroying threads (and can also control the amount of 
concurrency in an application) and ThreadLocals cache state which can be 
accessed without synchronization overhead.  Killing that every time a 
thread returns to the pool will make caching much less efficient.

> Hacks like the reflective code
> I linked to earlier that dump private fields seem a lot more "dangerous"
> to me, yet they are currently needed.

IMHO they are OK as long as they are used to log debugging warnings 
during development but as I said, a general mechanism to clear all 
thread locals does have more drawbacks than advantages.  Now you are 
hunting memory leaks through badly coded thread locals, then you might 
have to hunt down weird application behavior because of state 
disappearing which is expected to be still there.  Remember that *any* 
method in the thread's call stack can invoke cleaner which means that 
all methods upwards the call stack will not find their ThreadLocals back 
once control returns to them.

If we think about extending ThreadLocal's functionality at all then I 
would think in the direction of registering a cleanup handle (callback 
interface) with a ThreadLocal (or defining an empty method in 
ThreadLocal which can be overridden).  This handle would be invoked by 
the Thread itself prior to termination but could also be invoked by a 
thread pool or other framework.  Even that functionality might introduce 
bad bugs since - again - all methods on the call stack would be able to 
invoke it.  At least the creator of the ThreadLocal would have a chance 
to detect the situation and report a proper error (illegalstate for 
example).

Illustration

public class ThreadLocal<T> {
     static class ThreadLocalMap {

         private void remove(ThreadLocal<X> key) {
             Entry[] tab = table;
             int len = tab.length;
             int i = key.threadLocalHashCode & (len-1);
             for (Entry e = tab[i];
                  e != null;
                  e = tab[i = nextIndex(i, len)]) {
                 if (e.get() == key) {
                     // invoke cleanup code:
                     key.cleanup((X) e.value);

                     e.clear();
                     expungeStaleEntry(i);
                     return;
                 }
             }

   }

   /**
    * This method does nothing. Sub classes must override as they see fit.
    * @param the value of a thread which must be cleared.
    * @see #remove()
    */
   protected void cleanup(T val) {
     // nop
   }

   // Now we can even allow a cleanup all
   public static removeAll() {
     // pseudo code
     for (final ThreadLocal<?> tl : allLocalsOfThisThread()) {
       tl.remove();
     }
   }
}

However I think about it: the idea of simply clearing ThreadLocal 
references still does not become a good idea.  The creator of a 
ThreadLocal needs to consider how it is used and how cleanup is done. 
Everything else introduces dangerous side effects which lead to bugs 
which are at least as hard to find as those memory leaks.

Kind regards

	robert