[concurrency-interest]RE: comments on Executor
Sun, 3 Feb 2002 07:46:14 -0500
> Doug Lea wrote,
> > The main interaction with Executor classes is that any interrupted
> > thread should normally be discarded from the pool and replaced with
> > fresh one. Doing this regularly makes thread pools less efficient
> > than using a thread per task.
> What's the rationale for this?
A confluence of small reasons, that might each be addressible, but together
made this the best choice at least for dl.util.concurrent
* ThreadLocals, as you note
* It can otherwise be difficult to distinguish an interruption
originating from inside tasks versus interruptions from the Executor
itself to shut down the thread or pool.
* People used to report that in some JVMs, interrupted threads seemed
to randomly misbehave after a while. This was presumably due to JVM
bugs (hopefully now fixed) or maybe the user code was broken, but
after I adopted this (about 2 years ago?), complaints stopped. (One
difference between designing my package and creating an official
spec is that I was obligated to make many things work across common
JVM bugs and oddities. A spec shouldn't.)
> So, if in the general case tasks have to clean up on cancellation,
> then why not also require them to do threadLocal.set(null), or
> something equivalent, if cancellation has left threadLocal in a bad
This is difficult for user code to pull off. As you know, there is no
way to clear ALL the ThreadLocals for a given thread, and security
concerns argue against having such a method. Although it might be
worth investigating having a specialized version that can be called
only within trusted code base?
PS List Adminstrivia: I set the ("mailman" based) mailing list settings
to prefix list mail subject lines with "[concurrency-interest]" so
they are easier to distinguish.