[concurrency-interest] InterruptedException-free wrappers for calls that "will never be interrupted"
cpovirk at google.com
Tue Apr 13 21:44:00 EDT 2010
The main case I have in mind for uninterruptible methods is one that
I'm not sure how to put into your very (very! :)) rough categories.
I'm thinking of code that makes an RPC and waits for the result. In a
sense, there's no concurrency at all: The caller hands the request to
a network thread, which passes it to another process, which returns
the result, which is received by the network thread, which passes it
back to the caller. At each step, only one thread (sometimes a thread
in a different process entirely) is processing the request. The fact
that the original caller is waiting for another thread is almost an
artificial implementation detail of the RPC system, which happens to
need to demux the various responses it receives.
The caller of the RPC method, of course, can itself be placed into one
of your two rough categories. Maybe there are several running in
parallel, in which case cancellation may be valuable. But it's also
possible that only we're a boring web server making a single boring
request to the backend. Here cancellation via interruption seems like
a less important feature (if I'm understanding your comments).
Now, if cancellation via interruption were free, it might still be
worth supporting. But an extra checked exception has some cost to
callers, even those who don't expect to use it. I see an
uninterruptible wrapper as a way to reduce these costs for those
callers who don't see a corresponding benefit.
But since we're talking about RPCs, which already have other failure
modes, maybe interruption can be folded into the general
error-signaling framework. If the RPC framework declares "throws
ServiceException," maybe it should be catching InterruptedException
and, after restoring the interrupt, wrapping it in a ServiceException
(or subclass) and throwing that. I've seen this done but haven't
heard anything approach authoritative guidance.
(My RPC scenario may not generalize well beyond Future. I've used a
CountDownLatch to implement Future, but beyond that I'm not sure.
BlockingQueue was a request from a coworker; I suppose it could be
used similarly if the other process's response were streamed back
instead of returned as a single chunk.)
More information about the Concurrency-interest