Hi,<div><br></div><div>This is the detail problem, there is a small time window in which a 3 threads race makes select() always return 0 without blocking.</div><div><br></div><div>I wrote a testcase(<a href="http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/">http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/</a>) but it needs to modify the lib to reproduce, because the time windows is small.</div>
<div><br></div><div>The reproduce scenario is described in follow, use Tx for thread x:</div><div><p>1. T1 (the user code)   is selecting  a channel(suppose C), it just 
returns from native select function, and niolib select method is 
checking if the returned channel is interested in the event, then 2 
happens;<br>
2. T2 is closing  channel C, it just set the open variable to false but not yet closed the channel actually, and then 3 happens;<br>
3. T3 set the interedOps of the channel to 0. // 0 means the channel is 
not interested in anything, the channel will be put into cancel list 
normally.</p>


<p>In this senario, T1 returns from select, and return 0 which means no 
channel is selected(because the channel C returned from native 
invocation has nothing insterested in, it is not returned to application). 
Then T1 goes to invoke select again(usually in a loop, this is how 
select is designed to be used). In normal case, select method checks if 
any channels those should be cancelled and remove them from the set to 
be selected. Then, goes to native select function.</p>


<p>The problem is: select method first checks if the channel is closed, 
if it is closed, select method doesn&#39;t put it into cancel list. </p>


<p>In above senario, channel C is in close state, but not closed indeed,
 and setInteredOps to 0(which means cancel). So select method doesn&#39;t 
put C into cancel list(due to the problem) which means the native select
 set still contains channel C . So the native select always return C and
 nio select always return 0.  Until the channel is finally closed.</p><p><br></p><p>The testcase: <a href="http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/">http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev0.2/</a></p>
<p>A working fix: <a href="http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev_fix/">http://cr.openjdk.java.net/~zhouyx/OJDK-714/webrev_fix/</a>  </p><p><br></p><p>Please have a look.</p></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Wed, Dec 5, 2012 at 6:10 PM, Alan Bateman <span dir="ltr">&lt;<a href="mailto:Alan.Bateman@oracle.com" target="_blank">Alan.Bateman@oracle.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    On 05/12/2012 02:47, Sean Chou wrote:
    <blockquote type="cite">A small problem I&#39;m still checking. So the closeLock
      is just to make sure the channel is closed only once, is that
      right? </blockquote></div>
    This is how close is specified:<br>
    <br>
    
    &quot;If this channel is already closed then invoking this method has no
    effect.
    <p> This method may be invoked at any time. If some other thread has
      already invoked it, however, then another invocation will block
      until the first invocation is complete, after which it will return
      without effect.&quot;<span class="HOEnZb"><font color="#888888"><br>
    </font></span></p><span class="HOEnZb"><font color="#888888">
    <p>-Alan.<br>
    </p>
    <br>
  </font></span></div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br>Best Regards,<br>Sean Chou<br><br>
</div>