[concurrency-interest] InterruptedException-free wrappers for calls that "will never be interrupted"

Edward Harned edharned2002 at yahoo.com
Wed Apr 14 15:55:36 EDT 2010


Chris:

What an interesting session. 
But the real problem is interrupt().

You can sing and dance all day trying to handle InterruptedException
and re-throwing this and that, 
but you will never achieve a sustainable goal until you solve the basic problem.

Different programmers want to interrupt different code at different times 
and they think the interrupted code should behave the way the 
interrupters want it to behave. That can never be.

Doug Lea wrote, 
"interruption of any subtask wait doesn't imply anything ... 
instead you need explicit cancel()." 
Exactly. Dead on.

Do you want to interrupt some type of "wait" or 
do you want to tell the executing thread to stop what it is doing 
after the current iteration or drop dead now? 
And try to roll-back anything that it can or just leave it alone? 
etc.

interrupt() is currently overused/misused/course-grained in wishful thinking 
and can lead to erroneous results. 
It seems to me your options (as mentioned in your first post) 
can only make it worse. 
In both the concurrency environments mentioned by Doug Lea, we need a cancel().

Implement various, specific cancel() methods 
instead of trying to handle the indefinite interrupt().

Implementing a cancel() in an RPC environment requires a second client thread to 
"inform" the server code of the desired action since the original caller is
suspended waiting for a reply. 
(RPC is a a wee bit different scenario than your original "goal.") 

Ed





      


More information about the Concurrency-interest mailing list