Callback Based Selectors

[Alan Bateman]

On 20/03/2018 01:57, David Lloyd wrote:
> :
> Thinking about this some more, I am coming to believe that this is the
> crux of the locking problems we routinely encounter.  If we can get to
> a point where we can, in specification, state that select ops (or
> maybe even just the new select op(s)) will only hold the selector lock
> while blocking, then we are in an ideal situation as far as frameworks
> go because the aforementioned strategy (for channel registration which
> occurs concurrently to a selection operation) of "register and wakeup"
> will always work.  If we cannot do that in all cases though, we could
> mitigate it somewhat by having a method which can query the
> SelectorProvider to see if it needs to lock the key set, and choose an
> alternative implementation accordingly, for example using an external
> work queue to move the registration operation to the selector thread
> and then applying wakeup(), or having a selection callback perform a
> coordinated release of the key set's lock for the duration of the
> registration operation.
It requires significant refactoring but I think it should be possible to 
re-work the poll and select based implementations to not access the poll 
array during registration and changing interest ops. I think that would 
be better than having two code paths for every select usage. That said, 
implementations outside of the JDK will be a challenge. A useful 
property of the prototype API is that is that it can be implemented on 
the existing select methods.

-Alan