6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException

Chris Hegarty chris.hegarty at oracle.com
Tue Nov 9 08:12:10 PST 2010

Alan Bateman wrote:
> Rémi Forax wrote:
>> :
>> There is another bug, closeLock is not final in 
>> AbstractInterruptibleChannel.
> Thanks, I hadn't noticed that. I will fix that while I'm in the area.
>> :
>> can be changed to:
>> Thread current = Thread.currentThread();
>> if (current.isInterrupted())
>>     interruptor.interrupt(current);
>> to avoid to call Threa.currentThread twice.
> That is probably better.
>> About the patch, I'm not sure to fully understand it.
> The problem with the original implementation (this code is essentially 
> unchanged since 1.4) is that closing the channel may cause several 
> threads doing I/O on the same channel to observe the interrupted flag as 
> false and so will throw ClosedByInterruptException. Alternatively, if 
> some thread is just completing an I/O operation on the channel then it's 
> invocation of the "end" method will reset the flag. The changes just 
> mean that the intended thread will close the exception, other threads 
> doing I/O on the channel at round the same time will close 
> AsynchronousCloseException or have their I/O operations complete 
> successfully. If several threads doing I/O on the channel are 
> interrupted at around the same time then only one will throw 
> ClosedByInterruptException.

It seems unnecessary (but not wrong) to pass the current thread to the 
interruptor in AbstractSelector, null would be sufficient.

Would it be overkill/wrong to have a list of interrupted threads? 
Instead of just the last interrupted thread getting 

Otherwise, looks fine.


> -Alan

More information about the nio-dev mailing list