Callback Based Selectors

forax at univ-mlv.fr forax at univ-mlv.fr
Wed Mar 14 15:14:48 UTC 2018



----- Mail original -----
> De: "David Lloyd" <david.lloyd at redhat.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Alan Bateman" <Alan.Bateman at oracle.com>, "nio-dev" <nio-dev at openjdk.java.net>
> Envoyé: Mercredi 14 Mars 2018 15:34:23
> Objet: Re: Callback Based Selectors

> Because of the way locking with selectors works, I would expect that
> most NIO frameworks are simply going to use this to populate a fast
> queue like ArrayDeque and then process all the events outside of the
> lock.  That's what we already do, and I think that others follow this
> strategy as well.  As far as that approach goes, I don't see any
> problem with this API.
> 
> A brand new API which doesn't have the same select-under-lock behavior
> would be nifty, but I think that's a much bigger "ask".

I think it's a lesser "ask", the Selector API is already small in term of number of methods, the main issue is the locking scheme,
that why i think it's easier to create a new API with no public locking scheme that trying to retrofit the Selector API.

Alan will know more but i believe that we have a separate class AsynchronousFileChannel instead of an asynchronous API in FileChannel for the same reason.  

Rémi

> 
> On Wed, Mar 14, 2018 at 9:16 AM, Remi Forax <forax at univ-mlv.fr> 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.
>>
>> 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/~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/
>>
>> -Alan
>>
> 
> 
> 
> --
> - DML


More information about the nio-dev mailing list