Callback Based Selectors

David Lloyd david.lloyd at redhat.com
Tue Mar 20 01:57:20 UTC 2018


On Thu, Mar 15, 2018 at 8:44 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>  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.

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.

-- 
- DML


More information about the nio-dev mailing list