Callback Based Selectors

[David M. Lloyd]

On 02/08/2016 08:56 AM, Richard Warburton wrote:
>> 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/

Unfortunately this only makes it worse, for a couple of reasons.

Firstly, the selected keys set is synchronized through various rules as 
described elsewhere in the Selector documentation.  This means that the 
proposed default implementation of the selectNow(Consumer) method will 
hold this lock off and on over the duration of its execution, whereas an 
"optimal" implementation would not (as this is part of the point of 
having this method).

Secondly, because this set is explicitly specified for concurrent 
access, it seems very easy to end up in a concurrent 
iteration/modification situation which may result in 
ConcurrentModificationException being thrown.

Maybe it would be better for the default implementation to copy and 
drain this set under synchronization, or else (also under 
synchronization) create a new iterator on each iteration of the loop 
which acquires and removes the first element, then calling the accept() 
method outside of the lock.
-- 
- DML