Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Steven Simpson <ss@domain.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: Wormholes
Date: Wed, 05 Sep 2012 23:26:06 +0100
Organization: A noiseless patient Spider
Lines: 125
Message-ID: <u40lh9-726.ln1@s.simpson148.btinternet.com>
References: <0ska4895k2mp2j5fb5p4qnue7lsbdpoeoo@4ax.com> <9mbhh9-mce.ln1@s.simpson148.btinternet.com> <aapoq4F75iU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: mx04.eternal-september.org; posting-host="82310ab08bf578f62a5b66a5c4f3702f"; logging-data="19669"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Mw7s4zfJLd90XdXqPwQj55PdMI0i2DMA="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
In-Reply-To: <aapoq4F75iU1@mid.individual.net>
Cancel-Lock: sha1:0wQvfSl/122WKgrqVXWUbnEXqAE=
Xref: csiph.com comp.lang.java.programmer:18561

On 05/09/12 20:51, Robert Klemme wrote:
> I knew finally someone would suggest ThreadLocal for this.  This might 
> be even worse than global variables, especially since you pass hidden 
> state which usually makes testing more difficult.

Quite; that's why I started with: "Assuming that you can't improve your 
structure or refactor, ..."  That is, others' advice is to be tried first.

> The proper approach would be to pass the state down the call chain.

You're probably right, but there's not enough information in the stated 
problem.  I'd recently experienced a specific version of the problem, 
and mentioned how it was solved.  For me, the "incommensurate ripples" 
would be a use-specific change in an API.

> IMHO the best usage for ThreadLocal is to cache state *inside a class* 
> if calls may be concurrent and the cost of creating the state is 
> significantly high.  But using it to pass information between classes 
> because one wants to avoid adding method parameters is asking for 
> trouble.

I'll be more specific with the example I gave.  Here's an abridged API 
for a hierarchical structure that can be serialized:

   abstract class Box {
     List<Box> children;
     abstract InputStream getFieldContent();

     final InputStream getChildContent() {
       List<InputStream> streams = new ArrayList<>(children.size());
       for (Box child : children)
         streams.add(child.getContent());
       return new SequenceInputStream(Collections.enumeration(streams));
     }

     final InputStream getContent() {
       return new SequenceInputStream(getFieldContent(), getChildContent());
     }
   }

Several library-defined extensions are provided, implementing 
getFieldContent() in various useful ways.

Outside the library, there's a user creating a custom box type, making a 
hierarchy including it, and caching it:

   class MyAppSpecBox extends Box {
     InputStream getFieldContent() {
       ...
     }
   }

   // Create hierarchy out of library Box extensions.
   Box root = ... ;

   // Add the custom box type somewhere in the hierarchy.
   Box myBox = new MyAppSpecBox();
   root.children.get(2).children.get(1).children.add(myBox);

   cache.store(key, root);

Fetch it later, and serialize it:

   Box root = cache.fetch(key);
   InputStream in = root.getContent();

Suppose we want MyAppSpecBox.getFieldContent() to use a context which is 
known only at the point of fetching from the cache.  We don't control 
the Box API, and even if we did, we couldn't add an application-specific 
parameter to the getContent() family of methods.  How would we add a 
generic one, one that would be usable by several users independently and 
simultaneously (other than the Context<T> class I suggested, which is 
just a variation on ThreadLocal<T>)?

If we could locate myBox from root, we could pass the context to it 
after fetching.  However, traversing the full hierarchy or even knowing 
the correct path seem clumsy ways to locate it.  Also, its storage of 
the context would not be thread-safe.

So, we throw in a ThreadLocal:

   static ThreadLocal<Context> context = ...;

   class MyAppSpecBox extends Box {
     InputStream getFieldContent() {
       Context ctxt = context.get();
       ...
     }
   }

We set it before invoking the hierarchy:

   Box root = cache.fetch(key);
   Context ctxt = new Context(...);
   context.set(ctxt);
   InputStream in = root.getContent();


> Also, you need to be aware that the lifetime of these objects can be 
> quite long (there was a discussion about various aspects of 
> ThreadLocal in light of thread pools here earlier).

That use of ThreadLocal was preserving state from one 'prong' of the 
stack to the next, presumably with no way to inject a 
ThreadLocal.set(null) at a common vertex of those prongs.  This use of 
ThreadLocal only pushes values up the stack, which allows us to be more 
rigorous:

   Box root = cache.fetch(key);
   Context ctxt = new Context(...);
   context.set(ctxt);
   try {
     InputStream in = root.getContent();
   } finally {
     context.set(null);
   }


Cheers,

Steven

-- 
ss at comp dot lancs dot ac dot uk