Callback Based Selectors

Thu Mar 15 06:12:40 UTC 2018

Hi David,

I think if you are planning on just using the callback based selector to
populate an arraydequeue then Alan's proposed alternative of having a more
efficient specialised set implementation might be worth considering.

The motive for the callback approach was to avoid the overhead of the
adding then immediately removing selectionkeys but also to hopefully try
and simplify the locking model a bit. Iirc a selectnow() call entailed
acquiring 3 different locks within the selector. I don't think this was
required by the callback based mechanism, however as Alan points out that
was never properly reviewed at the time.

I actually like Remis proposal of having a different selector with a
different locking model. That would fit my use cases where selectors are
used essentially single threaded in an event loop really well. I never
originally proposed this more because of a fear that such a large change
would be highly likely to be rejected rather than on the basis of technical
merit. I don't know what people on the core libs team feel about this
approach?

On Wed, 14 Mar 2018, 16:35 David Lloyd, <david.lloyd at redhat.com> wrote:

> 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".
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180315/9b224d63/attachment-0001.html>