Review Request : JDK-8002306, (se) Selector.open fails if invoked with thread interrupt status set [win]

[Dan Xu]

On 12/12/2012 04:57 AM, Alan Bateman wrote:
> On 10/12/2012 22:28, Dan Xu wrote:
>> Hi folks,
>>
>> Please help review the fix for JDK-8002306, Selector.open fails if 
>> invoked with thread interrupt status set [win], at
>> http://cr.openjdk.java.net/~dxu/8002306/webrev/ 
>> <http://cr.openjdk.java.net/%7Edxu/8002306/webrev/>
>>
>> On windows, we establish loopback socket connections every time a 
>> selector is opened. But the connect operation will fail and throw out 
>> ClosedByInterruptException if its current thread is interrupted. In 
>> order to open a selector on an interrupted thread successfully, the 
>> fix clears the interrupt status, establish socket connections, and 
>> reset the status to interrupt afterwards to work around the 
>> restrictions. Thanks!
>>
>> -Dan
> I looked at the proposed change, but I think it could be a bit simpler 
> (meaning no null or isConnected checks) if we simple start over when 
> ClosedByInterrupt is thrown. So if open(sa) fails then ssc.close and 
> retry, if accept() fails then sc1.close ssc.close and retry. I think 
> that would make it easier to verify too. I'm interested in David 
> Lloyd's comment about a timing issue as he may be seeing something 
> that I don't see.
>
> On the test then I don't think @library is needed. Also would be good 
> if this test didn't have to run in othervm mode. If the test closes 
> the Selector then I think it should be good to run in agent VM mode 
> (meaning it can run in an existing VM, doesn't need to spin up a new 
> VM for the test). Also what would you think about beefing it up so 
> that pounds a thread calling Pipe.open with Thread.interrupt, I think 
> this is the only way that this can be properly tested.
>
> -Alan

I have updated my fix at, 
http://cr.openjdk.java.net/~dxu/8002306/webrev.01/ 
<http://cr.openjdk.java.net/%7Edxu/8002306/webrev.01/>.

It removes checks of null or isConnected, and also addresses a potential 
race situation by using an uninterruptible thread to establish the 
loopback connections, which is the last resort to solve the connection 
failures. In addition, the test is also updated to test the pipe 
directly. Please review the new changes. Thanks!

-Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121218/564d91d6/attachment.html