-
Enhancement
-
Resolution: Fixed
-
P4
-
None
-
b09
This is follow-up to the clean-ups to the Selector implementations in JDK-8199791, JDK-8200179, and JDK-8200257. This time we have:
- interestOps does not need to queue the translated ops to the Selectors. Instead, the Selector can ask the key for the translated ops. This will reduce the need to queue the changes to the ops and will avoid the update processing from updating the kernel more than once for the same file descriptor.
- implRegister does not need to queue the key to be registered, it can be done by the first interestOps. This helps the initial registration as it means the key is queued once, rather than twice.
- SelectionKeyImpl.channel should be private, the Selector implementations can invoke translateXXX methods on the key instead.
- The /dev/poll Selector on Solaris handles EINTR in native code, this should be make consistent with the other implementations and be handled at the java level.
- interestOps does not need to queue the translated ops to the Selectors. Instead, the Selector can ask the key for the translated ops. This will reduce the need to queue the changes to the ops and will avoid the update processing from updating the kernel more than once for the same file descriptor.
- implRegister does not need to queue the key to be registered, it can be done by the first interestOps. This helps the initial registration as it means the key is queued once, rather than twice.
- SelectionKeyImpl.channel should be private, the Selector implementations can invoke translateXXX methods on the key instead.
- The /dev/poll Selector on Solaris handles EINTR in native code, this should be make consistent with the other implementations and be handled at the java level.
- relates to
-
JDK-8210917 (se) Re-implement Windows Selector
-
- Closed
-
-
JDK-8199791 (se) More Selector cleanup, part 1
-
- Resolved
-
-
JDK-8200179 (se) More Selector cleanup, part 2
-
- Resolved
-
-
JDK-8200257 (se) More Selector cleanup, part 3
-
- Resolved
-