Possibly we are on illegal territory with the premise for this problem: updating the events of interest for a SelectionKey while another thread is sleeping in a poll on that key.
This update works using the DevPollSelector.
While "it works using DevPoll" does not make it right, it would offer less surprise to the programmer if we had the as much as possible the same behaviour in each implementation. Plus, implementing the simple list of udpates is straightforward.
While we warn in the API docs that Selectors are safe to use in multiple threads but their keys are not, it would be nice to make as much as possible of this API safe across multiple threads. Also, from reading the API document it's not 100% clear that what we are doing is illegal: we are only updating a key's interest events in one thread at once.
###@###.### 2005-07-08 16:32:55 GMT
###@###.### 2005-07-11 18:13:17 GMT
This update works using the DevPollSelector.
While "it works using DevPoll" does not make it right, it would offer less surprise to the programmer if we had the as much as possible the same behaviour in each implementation. Plus, implementing the simple list of udpates is straightforward.
While we warn in the API docs that Selectors are safe to use in multiple threads but their keys are not, it would be nice to make as much as possible of this API safe across multiple threads. Also, from reading the API document it's not 100% clear that what we are doing is illegal: we are only updating a key's interest events in one thread at once.
###@###.### 2005-07-08 16:32:55 GMT
###@###.### 2005-07-11 18:13:17 GMT
- duplicates
-
JDK-6240230 (se) Selector doesn't act on keys with matching interestOps and readyOps
-
- Closed
-
- relates to
-
-
- Closed
-