Callback Based Selectors

[Richard Warburton]

Hi David,

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.
>>
>
> Hi Richard.  Selector specifies a relatively extensive contract with
> respect to locking.  It is not clear from the documentation of the new
> method what the behavior is with respect to the various selector locks.
> Looking at the code, it seems to sidestep locking altogether during the
> callback process, is that an accurate assessment?
>

Simple question, complex answer ;)

Doing a select() or selectNow() involves 3 sets of locks. One of them is on
the hashset for selection keys, one on a unmodifiable view over the keyset
of said map and one is a lock that manages the platform specific
implementation of the Selector. All 3 of these sets of locks are managed
across all the different platform specific backends from the SelectorImpl
class.

The callback based selector retains the lock for the backend, but ignores
the other two sets of locks because its not interested in the selection key
set. My expected usecase is that people either call the callback based
select or the other select implementations and not both on a single
selector. I believe, but would love more code-review from Nio experts to
validate my understanding, that the code I've written is threadsafe for
multiple threads all calling the callback based selector.

Does that make sense?

Also, any thoughts on compatibility implications in terms of existing
> Selector subclasses?  I don't think such a thing is common, but the class
> is public and has an accessible constructor.  The addition of the new
> abstract method could theoretically result in unexpected
> AbstractMethodErrors.
>

Interesting point. It would be simple to add a dumb default implementation
on the public class that delegates to the existing select()/selectNow()
calls.

When writing the patch I hypothesized that the only who maintain subclasses
of Selector maintain their own JVMs and probably could be encouraged to
port the patches. You're right though that its safer to provide a default
implementation on the public class. I'll push an updated patch hopefully
over the weekend.

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/20160122/6f4ade99/attachment.html>