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

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

Re: Proposed new Java feature

Show all headers | View raw

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

Back to comp.lang.java.programmer | Previous | Next — Previous 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