Re: Wormholes
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