[concurrency-interest] Offering data to Futures

David M. Lloyd david.lloyd at redhat.com
Tue May 26 15:25:56 EDT 2009

On 05/26/2009 01:34 PM, karlthepagan wrote:
> One thing I haven't decided yet is how to propagate 
> InterruptedIOException in the API. In the case that IO is canceled the 
> number of bytes written before interruption may be significant. That 
> byte count isn't communicated by cancel/isCanceled so I've considered 
> either subclassing CancellationException to hold this info or wrap it 
> using ExecutionException.

I've found it to not be an issue so far.  With low-level I/O, NIO-class 
operations are generally atomic and non-blocking.  So in the case of 
writes, either data was successfully written, in which case the result is a 
byte count, or the thread was interrupted before the write took place so 
nothing is written at all.  Likewise for reads, connects, accepts, etc.  If 
the writer thread is interrupted after or even during the write, the caller 
would never need to know about it anyway.

With high-level I/O (like remote invocations for example), interruption 
doesn't enter into it at all.  If the local (waiting) thread is 
interrupted, it is your option whether to fire off a cancellation on the 
IoFuture or just let it finish.  If the remote invocation is interrupted, 
the framework would relay the result as a general cancellation (i.e. 
operation failed, request was received but operation wasn't yet started, 
request was not fully received, etc).  And cancellation may itself 
interrupt the remote invocation (why not?) as the mechanism by which 
cancellation is effected.  In any case, the mechanics of the cancellation 
is an implementation detail and it won't make a difference to the caller 
whether there was an actual interrupt or not.  The only possible surprise 
is that a cancellation might happen without the initial caller actually 
calling "cancel()" - for example if the remote side is being shut down when 
an invocation is made.

I believe there is some history with respect to InterruptedIOException and 
the design of interruption with blocking I/O - I'm sure I remember Alan 
Bateman discussing it on the NIO.2 list not long ago.  In any case I guess 
we're rapidly diverging from the parameters of concurrency-interest. :-)


More information about the Concurrency-interest mailing list