Callback Based Selectors

[David Lloyd]

On Wed, Mar 14, 2018 at 9:05 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> Locking was mostly ignored in the original prototype but the locking has to
> be consistent with how the existing selection operations are specified. The
> main reason is processing the cancelled-key set means removing keys from the
> key set and selected-key set. On the surface, the new methods should not
> care about the selected-key set but they have to maintain the invariant that
> the selected-key set is always a subset of the selector's key set.

One thing worth noting is that it is possible for the callback code to
temporarily release the lock by calling Object.wait on the selector
instance.  I think that your reentrancy guard will protect against any
problems that could result - in fact this may in the end become a
desirable technique, for certain specific cases at least - but I
wanted to make sure that it was specifically called out to make sure
it doesn't get forgotten.

One other thing I was wondering is whether it might be a good idea to
process cancelled keys *after* the selection callbacks are complete,
either in addition to or instead of processing after selection but
before the callbacks are called?  I think it would not be unusual for
a callback to cancel selection key(s) during the course of its
processing.

Overall this proposal is growing on me quite a lot.

-- 
- DML