Callback Based Selectors

[Alan Bateman]

On 29/03/2018 22:22, David Lloyd wrote:
> On Wed, Mar 28, 2018 at 3:15 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> I don't think there is an issue there as a sequence of callings to
>> interestOpsXXX will just queue the translation of the interest ops.
> OK I've given it another go.  I haven't even been able to compile-test
> it yet though due to [1].  In particular, I'm not certain I can
> properly set up the VarHandle the way I have.  But I wanted to review
> the basic idea.
>
> Using atomics, and assuming I understand how the op queueing is
> supposed to work, we can actually optimize a bit because we can avoid
> calling nioInterestOps(int) unless a new bit has been added which
> wasn't there before.
>
Suppose the interestOps is 0. T1 invokes interestOpsOr(OP_READ) at 
around the same time that T2 invokes interestOpsOr(OP_WRITE). The 
interestOps field will get to OP_READ|OP_WRITE as you'd expect but there 
is no guarantee that the last change queued to the selector is the 
equivalent events (POLLIN|POLLOUT in this case).

I don't have time just now to go into this in more detail but if you 
change the putEventOps implementations to:

int ops = ski.interestOps();
updateEvents.addLast(ski.channel.translateInterestOps(ops));

then the selection operation will read the newest value of the interest 
set (further changes will be picked at the next selection).

Once the queuing of updates is changed (to drop updateEvents) then this 
will be a lot simpler.

-Alan