[concurrency-interest]RE: comments on Executor

Doug Lea dl@cs.oswego.edu
Sun, 3 Feb 2002 07:46:14 -0500

Miles wrote:

> 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 
> state?

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.