Callback Based Selectors

[Remi Forax]

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. 

regards, 
Rémi 

> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> À: "Richard Warburton" <richard.warburton at gmail.com>, "nio-dev"
> <nio-dev at openjdk.java.net>
> Envoyé: Mercredi 14 Mars 2018 15:05:58
> Objet: Re: Callback Based Selectors

> On 16/01/2016 11:14, Richard Warburton wrote:

>> Hi gents,

>> I've prototyped a callback based addition to the NIO Selector, which I've
>> previously talked through a bit with Alan Bateman. The goal of the callback
>> based selector is to avoid the current pattern of calling select/selectNow on a
>> Nio selector and then having to iterate over a hashmap produced. This pattern
>> being quite object allocation heavy for a critical path and also involving
>> obtaining and releasing multiple locks. I'd like to propose that the following
>> patch, which adds the ability to perform a select on a Selector that takes a
>> callback handler.

>> [ http://cr.openjdk.java.net/%7Erwarburton/select-now-4/ |
>> http://cr.openjdk.java.net/~rwarburton/select-now-4/ ]

>> I'm happy to iterate on the patch a bit based upon people's feedback and discuss
>> any potential concerns or issues that you may have with the patch. Looking
>> forward to hearing your feedback.

> This one has been on my list for a long time to study more closely. When we
> discussed it here in 2016 I had concerns about invoking a consumer while
> synchronized on the selector and other locks. It has grown on my a bit so I
> spent a bit of time recently to work through the implications, both spec and
> implementation.

> For the spec: The Selector API describes selection operations in its class
> description and it's important to keep that consistent when introducing a new
> way to be notified of channels ready for I/O operations.

> The action is arbitrary code and we have to assume it will behave as if it's a
> bull in a china shop. It might attempt another selection operation on the same
> selector, it might close the selector, it might change the interest set or
> cancel a key for a channel registered with the selector but not yet seen by the
> consumer. All of these scenarios need consideration.

> Locking was mostly ignored in the original prototype but the locking has to be
> consistent with how the existing selection operations are specified. The main
> reason is processing the cancelled-key set means removing keys from the key set
> and selected-key set. On the surface, the new methods should not care about the
> selected-key set but they have to maintain the invariant that the selected-key
> set is always a subset of the selector's key set.

> Another point of detail is that the action may need to be called more than once
> for the same key but different ready sets. We have this with the kqueue
> implementation where events for read and write are registered with different
> filters. Other implementation might maintain separate poll arrays for read and
> write events.

> In terms of performance, the main benefit is that avoids adding keys to the
> selected-key set, only to be removed almost immediately by the code doing the
> select. This avoids garbage so helps the GC too. If we go ahead with these
> methods then it's important to get a good range of performance data and also
> see whether a specialized set to support the usage pattern of the selected-key
> set might be alternative to introducing new APIs.

> I've put a webrev here with candidate changes to the Selector API. It's one
> select(Consumer<SelectionKey>, timeout) for now, the
> select(Consumer<SelectionKey>) and selectNow(Consumer<SelectionKey>) variants
> are easy to add if needed. The webrev has a default implementation based on the
> existing API, and then implementations for macOS and Linux. Other platforms
> could be added later of course. I've also included a test that covers most of
> the scenarios.
> [ http://cr.openjdk.java.net/~alanb/8199433/webrev/ |
> http://cr.openjdk.java.net/~alanb/8199433/webrev/ ]

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