[concurrency-interest] Soliciting input about removeAllThreadLocals
Mon, 09 Dec 2002 14:27:33 -0800
>> By the way, I don't really understand your beef with the current
>>thread local facility (which I happen to like much more than its
>I'm just curious: why? AFAICS, the main difference is the addition
>of an extra state [used/non-used] to support initialValue() plus
>somewhat murky [suddenly we've got parents/childs among threads]
>"inheritability" on one hand, and on the other hand, the *lack* of
>destructors/cleanupors-if-you-like invoked at thread termination
>time; and in the context of terminating thread.
Nope. You're missing the main point. In pthreads (and in all 5
home-brewed thread-local-storage solutions that I saw prior to designing
ThreadLocal) explicit, forgeable keys were used to acess a thread-local
variable. In the case of pthread_getspecific it was the first argument
(pthread_key_t key). In the case of all the home-brewed solutions I saw
(both inside and outside Sun!), people used strings as keys. This is an
awful idea, as all hell breaks loose when two people pick the same
string, or when a hacker attempts to guess the key you used, to peak (or
poke) at the data. A simple fix would be to use unforgeable object keys
(capabilities). The clever realization that makes the current design
nice is that there's no need for a separate key object. (This is
discussed in a bit more detail on pages 152-154 of "Effective Java.")
> But that's it, so to speak. Or am I just missing
>and/or misunderstanding something? I'd say that "language" support
>ala sort-of-upcoming C/C++'s "__thread" storage [but that would also
>work with dynamic init and would be "fully lazy"] would be much more
>fun-to-use in many [but not all] cases.
I suggested this in '97, but the suggestion was met with lukewarm
response. The libary solution represents a compromise.
>Well, concerning the subject of this thread, I don't like removeAll-
Glad to hear it!
P.S. I admit that InheritableThreadLocal was a bit speculative but I
think it has proven useful to a number of people.