Callback Based Selectors

[Alan Bateman]

On 14/03/2018 14:16, Remi Forax wrote:
> I wonder if it's not better to have a new Selector class, let say 
> CallbackBasedSelector (or whatever) than trying to retrofit the 
> Selector API to work in both mode at the same time.
> Obviously, the implementation can be based in the same code but from 
> the user POV you can not both API at the same time.
>
Given the potential for Fibers in the future, I think we need to be 
cautious about introducing new big APIs in this area. In addition, a 
completely different Selector type brings a lot of potential issues, 
esp. if a selectable channel is registered with an existing Selector and 
something else.

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.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180315/4749a76d/attachment.html>