RFR[11] of JDK-8208280,java/nio/channels/Selector/RegisterDuringSelect.java fails with "key not removed from key set"

[Hamlin Li]

Ping


On 2018/7/30 1:38 PM, Hamlin Li wrote:
>
>
> On 2018/7/27 4:52 PM, Alan Bateman wrote:
>> On 27/07/2018 07:58, Hamlin Li wrote:
>>> Would you please review the following patch?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208280
>>>
>>> webrev: http://cr.openjdk.java.net/~mli/8208280/webrev.00/
>>>
>>>
>>> The issue may occur intermittently, the main reason is that on 
>>> windows Pipe is implemented as a pair of socket, so sinked byte 
>>> might not be immediately available at source side. Steps for the 
>>> issue to occur:
>>> 1. 2nd sel.wakeup() is invoked before 2nd select() and the sinked 1 
>>> byte is not read out by resetWakeupSocket0 because it might not be 
>>> immediately available at source side and ioctlsocket may report 0 
>>> byte, so select() return quickly before invocation of native 
>>> select() method;
>>> 2. the previously sinked 1 byte arrives at source side;
>>> 3. 3rd select() is invoked and finishes quickly before 
>>> key.cancel()/sel.wakeup() is invoked because previously sinked 1 
>>> byte is still in source side;
>>> 4. after 3rd select() returns, key.cancel() is invoked but it has no 
>>> effect on sel.keys(), so sel.keys() still contains the just canceled 
>>> key.
>> Thread.sleep is going to be problematic here. Also the duration is 
>> nothing to do with the timeout factor specified to jtreg so I don't 
>> think we should be using adjustTimeout either. Instead I think we 
>> will need to change this test to synchronize with the selection 
>> operations.
> As the root cause is 2nd wakeup will impact not only 2nd select but 
> possibly 3rd select at some situation, so I think it's better to 
> separate all the tests totally, i.e. setup selector for every test 
> freshly, rather than reuse selector among these tests.
> new webrev: http://cr.openjdk.java.net/~mli/8208280/webrev.01/
>
> Thank you
> -Hamlin
>>
>> -Alan
>>
>>
>