Callback Based Selectors

[Richard Warburton]

Hi,

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.
>

I've pushed a default implementation for the Selector API to avoid this
compatibility problem:

http://cr.openjdk.java.net/~rwarburton/select-now-5/

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/20160208/e46e9ee5/attachment-0001.html>