Request for review / feedback: SocketChannel.poll()

[David M. Lloyd]

On 10/02/2013 10:18 PM, Alan Bateman wrote:
> On 02/10/2013 14:03, David M. Lloyd wrote:
>> :
>>
>> 1. Thread interruption should stop the poll, but absolutely should not
>> *not* close the channel - that was a bad idea at its inception and it
>> is still a bad idea now, and people who do not want this behavior (==
>> sane people) will still be stuck with using temporary selectors.  It
>> is up to the application to decide what thread interruption means.
>> InterruptedIOException is more appropriate, and the user can elect to
>> close the channel if they feel it is appropriate to do so.
>> Inconsistency is worthless if the existing behavior does not make sense.
> You are correct that there is a bug in the proposal as the poll is
> supposed to behave in the same way as Selector.select when interrupted
> (which means it is supposed to wakeup the poll).
>
> I don't have time to debate your comments on InterruptedIOException as
> that was totally broken, we don't want to go back there.

Ha, so much hate for InterruptedIOEException.  I actually use it 
commonly (with a transferred count of 0) as a general purpose indication 
that an I/O op was interrupted.  In my code I do not support partial 
transfers (unless I am implementing an API that does), so the user 
doesn't actually have to introspect the count.  Unfortunately there does 
not seem to be an alternative exception type that indicates interruption 
(without other nasty effects like channel closure) and also extends 
IOException, which is the reason I've used it.

Simply causing a wakeup is OK, however it does cause the user to have to 
check the thread interrupted status after every poll, which they are 
going to forget to do.
-- 
- DML