Callback Based Selectors

[David M. Lloyd]

On 01/18/2016 11:56 AM, Alan Bateman wrote:
> On 18/01/2016 16:00, David M. Lloyd wrote:
>>
>> 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.

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.

-- 
- DML