Date: Mon, 14 May 2001 08:23:51 -0700
From: ###@###.###

> Date: Sat, 12 May 2001 00:16:21 -0400 (EDT)
> From: ###@###.###

> - There is a race between how an AbstractSelectableChannel gets closed
> and how SelectorImpl processes its cancelled key set and analyzes the
> results of a poll() call.

Yes. A fix for this is to have AbstractSelectableChannel.implCloseChannel
cancel keys before, rather than after, invoking implCloseSelectableChannel.
(We can't make closing atomic with respect to select operations since that
would make it impossible for one thread to close a channel while another is
selecting on that channel; allowing that is the whole point of the
key-cancellation mechanism.)

> - SelectorImpl.select() should be robust in the face of asynchronous
> SelectionKey cancellations.

This one's easier -- we can synchronize on the cancelled-key set across the
post-poll invocations of processDeregisterQueue and updateSelectedKeys.

> ? Should SelectorImpl.select() re-invoke poll(), rather than return
> zero, if there was no wakeup or interrupt, no timeout, and no new
> ready events to report on unclosed channels?

Yes, as should select(long), though that one's a little trickier due to the
timeout argument -- we'll have to keep track of when we started in order to
ensure that we don't block for more than (approximately) the total requested
timeout.