Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I would guess that the proposed snippet would not work at all in principle, per the contracts of <code>Selector#select()</code> and <code>Selector#selectedKeys()</code>. From <a href="http://java.sun.com/javase/6/docs/api/java/nio/channels/Selector.html" rel="nofollow noreferrer">Selector</a>:</p> <blockquote> <ul> <li>The selected-key set is the set of keys such that each key's channel was detected to be ready for at least one of the operations identified in the key's interest set during a prior selection operation. This set is returned by the selectedKeys method.</li> </ul> </blockquote> <pre>public abstract int select(long timeout) throws IOException Returns: The number of keys, possibly zero, whose ready-operation sets were updated </pre> <p>As I read that, the size of the <code>selectedKeys</code> set should always equal the number returned by <code>select</code> by definition. I have noticed - as you may have as well - that some implementations don't quite follow the documentation, and in fact <code>selectedKeys</code> returns all keys with updated ready-operation sets, even if they were not updated during a call to <code>select</code>. The only other indicator that the select woke up due to a call to <code>wakeup</code> might be that the number of keys is zero; however either method would be unreliable, at best.</p> <p>The usual way to handle this is, as implied, through concurrency control. I wouldn't worry about execution time here; this is a classic example of <a href="http://en.wikipedia.org/wiki/Optimization_(computer_science)#When_to_optimize" rel="nofollow noreferrer">premature optimization</a>.</p> <p>Unless you're really worried about single digit microsecond tolerances, you won't notice any slowdown - and if you are worried about that level of tolerance, a <code>Selector</code> isn't going to be reliable enough for you anyway.</p> <p>Here's an example of the usual mechanism for this, using a <code>ReentrantLock</code> to accomplish the appropriate concurrency:</p> <pre><code>ReentrantLock selectorGuard; Selector selector; private void doSelect() { // Don't enter a select if another thread is in a critical block selectorGuard.lock(); selectorGuard.unlock(); selector.select(); Iterator&lt;SelectionKey&gt; keyIter = selector.selectedKeys().iterator(); while(keyIter.hasNext()) { SelectionKey key = keyIter.next(); keyIter.remove(); // Process key } } private void addToSelector() { // Lock the selector guard to prevent another select until complete selectorGuard.lock(); try { selector.wakeup(); // Do logic that registers channel with selector appropriately } finally { selectorGuard.unlock(); } } </code></pre>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload