[concurrency-interest]RE: comments on Executor

Miles Sabin msabin@interx.com
Sun, 3 Feb 2002 13:06:00 -0000


Doug Lea wrote,
> Miles Sabin wrote,
> > 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?

Isn't this just an application design issue tho'? User code intended
for interruptible contexts ought to be able to clean up after itself
(which might mean keeping references to ThreadLocals handy, amongst
other things), and we shouldn't have to worry about system code,
because that's guaranteed to behave correctly, obviously ;-)

So, I guess my worry is that the rationale boils down to defensivness
in the face of broken JVMs and/or user code which isn't designed to
cope with cancellation. That's not unreasonable, but it does impose a
significant performance penalty where cancellation is used heavily.

That said, I'm open to the counter-argument that software which makes 
heavy use of async cancellation gets what it deserves.

Cheers,


Miles

-- 
Miles Sabin                                     InterX
Internet Systems Architect                      27 Great West Road
+44 (0)20 8817 4030                             Middx, TW8 9AS, UK
msabin@interx.com                               http://www.interx.com/