Callback Based Selectors

[Richard Warburton]

Hi David,

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?
>>>
>>> Right, this is a concern that I brought up with Richard when we
>> originally chatted about this a long time back (I think at JavaOne
>> 2014). I haven't had a chance yet to look at the current proposal but it
>> would minimally need a big warning as it would be too easy to cause
>> deadlocks and other issues when not used correctly.
>>
>
> I want to clarify that this change looks like a great idea to me: a start
> to cleaning up the Selector API, which has some serious problems
> (especially in terms of concurrent access).  But these questions do need to
> be answered.
>

Thanks, the feedback is most appreciated.

In the long term it seems important to have a Selector API (or
> Selector-equivalent API) in which interest ops can be concurrently added or
> modified completely locklessly (though I generally expect that "poking" the
> selector to wake up will always be necessary when any of this is modified
> from another thread while the selector is selecting). I think this API
> change might be a good first step, if it can be determined how the
> callback-signaled operations relate to the various key sets and their locks.
>

I agree that lockfree modification would be nice. At the moment the close
lock in the selector implementations looks like it exists to protect a
single boolean variable ie, could just be a volatile. This is perhaps
another step in that direction, but feels like it should be kept as a
separate patch.

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/81a1b3d0/attachment.html>