[concurrency-interest] InterruptedException-free wrappers for calls that "will never be interrupted"
edharned2002 at yahoo.com
Wed Apr 14 15:55:36 EDT 2010
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?
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.")
More information about the Concurrency-interest