Callback Based Selectors

[David Lloyd]

On Thu, Mar 15, 2018 at 7:11 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 15/03/2018 11:49, David Lloyd wrote:
>> A specialized set isn't really interesting to me because I have to
>> process it outside of the lock(s) anyway.  ArrayDeque works well for
>> me because once it's sized, it's very fast, and by using the callback
>> to populate it we avoid the extra add/remove operation on the key set,
>> which is already worth something to me.
>>
> Which lock are you trying to avoid here? Selection operations are specified
> to synchronize on the selector, its key set, and the selected-key set. The
> existing select methods add to the selected-key set and must maintain the
> invariant that the selected-key set is a subset of the selector's key set.
> The method on the table has the potential to release the locks for the key
> set and selected-key once it has processed the cancelled-set key, meaning
> that the only lock held when invoking the consumer is the selector lock.

I need to process events outside of the lock because I need to be able
to register and cancel keys from the same or different threads at any
time; processing events under the lock means that the lock will be
held almost 100% of the time in my selector loop, preventing other
threads from doing things like cancelling or registering keys.  By
processing events outside of the lock, the only time the lock is held
for a significant amount of time is during selection operations, which
I can interrupt via wakeup() and careful handshaking.

If we can avoid the need for waking up the selector in order to grab
the lock to cancel or register keys though... that would be pretty
nice.  The three-lock model has historically been difficult since
different providers behaved a bit differently; we have a couple of
switches which relate to controlling the interaction behavior with
different selector providers today.

In the end what is needed is a clear model which describes not just
how the locking itself works, but how concurrent registration,
cancellation, and changing interest ops should work as a result.  I
should be able to asynchronously register or cancel a key and hit
wakeup() on the selector and have it just work.  Unfortunately that
isn't the case today.

-- 
- DML