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
ClosedByInterruptException.
Otherwise, looks fine.
-Chris.
>
> -Alan
>
More information about the nio-dev
mailing list