Callback Based Selectors

[Richard Warburton]

Hi Alan,

As regards Richard's proposal then it does fit with the existing Selector
> design. Rather than adding or updating keys in the selected-key set, it
> invokes an action that can collect or process the keys. Iterating over
> native events is essentially iterating over a region of memory so it has to
> synchronize on the selector to prevent it being closed or used for another
> selection operation. In terms of performance, this lock is in the noise in
> everything that I've tried but others have have benchmark showing different
> results (almost all of the locking issues that I've looked at come up in
> the context of changes to registration that are attempted concurrently with
> a selection operation). It would be feasible to specify that the only lock
> held when processing the events is the selector lock (it doesn't need to be
> synchronized on the selector's key or selected-key set for that phase of
> selection.
>

I don't have an open source benchmark to hand, but the general problem with
locks when it comes to benchmarks is that they can often be in the noise
when it comes to throughput but with tail-latency jitter when some other
thread just happens to contend with you in production. Either way I think
we're all happy to reduce the number of acquired locks as part of the
callback vs using selectNow() and then iterating the keys.

regards,

  Richard Warburton

  http://insightfullogic.com
  @RichardWarburto <http://twitter.com/richardwarburto>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180316/e78261e3/attachment.html>