8231603: (se) Selector implementations do not need to use cancelledKeys

[Brian Burkhalter]

> On Oct 1, 2019, at 9:19 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
>> On 1 Oct 2019, at 15:48, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>> 
>> This is a change to the Selector and SelectionKey::cancel implementations to avoid needing the cancelled-key set. Although specified, the cancelled-set key is not exposed in the API (except in implementations of AbstractSelector where the implementation has access to its own cancelled-key set) so the change should not be observable. The change has no impact on alternative implementations of AbstractSelector.  While in the area, I replaced the use of AtomicBoolean for the open state with a VarHandle.  I also inverted the valid flag in SelectionKeyImpl to that its initial value is false and so doesn't need to be initialized to true with a volatile write.
>> 
>> http://cr.openjdk.java.net/~alanb/8231603/webrev/index.html <http://cr.openjdk.java.net/~alanb/8231603/webrev/index.html>
> 
> Seems fine to me. ( I agree that the change should not really be observable )
> 
> I assume that the kind of access operations that the selector does, add keys & iterate over all keys, are more suited to a deque, and therefore faster ( than HashSet ).
> 
> The updates from j.u.c.atomic to VarHandle look fine too.

Agreed, this looks fine.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20191001/6539c442/attachment.html>