Callback Based Selectors

[Alan Bateman]

On 15/03/2018 13:01, David Lloyd wrote:
> :
> 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.
The register method is specified to synchronize on the selector's key 
set, the cancel method is specified to synchronize on the cancelled-key 
set. Neither is specified to synchronize on the selector itself.  While 
there are challenges, esp. with poll-based implementations, it should be 
possible to get to the point where the only lock held when invoking the 
action is the selector itself. Going further and not locking the key set 
during a select isn't hard on some platforms but posed challenges on 
poll or select based implementations.


>
> 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.
The locking is well specified so you shouldn't strictly need to be aware 
of which implementation is used.

-Alan