JDK 9 RFR of 8176332: Increase sleep time in java/nio/channels/Selector/ChangingInterests.java write1()

[Jon V.]

Plus the current code doesn't properly deal with Interrupts and could give
false-positives during automatic regression testing.

On Wed, Mar 8, 2017 at 5:02 PM, Jon V. <sybersnake at gmail.com> wrote:

> Oh duh! It was a/tests/  Can't believe I missed that.  For a second there
> I thought this was in the main.
>
> I still wouldn't rely on the scheduler, maybe do a little loop with an
> counter using System.currentTimeMills?
>
> On Wed, Mar 8, 2017 at 4:52 PM, Brian Burkhalter <
> brian.burkhalter at oracle.com> wrote:
>
>> Note that the sleep is only in the test, not the implementation code, and
>> version .01 of the patch does not depend on a fixed total length of sleep
>> but instead uses it only to pause before retrying. In almost all cases it
>> should never have to retry and will not hit the sleep. If for some reason
>> the loop continues indefinitely hitting the sleep, the test will time out.
>>
>> Brian
>>
>>
>> On Mar 8, 2017, at 1:47 PM, Jon V. <sybersnake at gmail.com> wrote:
>>
>> Thread.sleep is always going to go back to the kernel scheduler clock
>> anyways.  The kernel scheduler clock could be 1khz or 24hz; you shouldn't
>> rely on it to perform timed operations this way.
>> https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt
>>
>> Thread.sleep is a blocking operation.  Sleeping a thread in order to wait
>> for another thread or external action to be performed is not sound.
>> Increasing the time may fix the bug reported but may also make a lot of
>> existing working code much slower.  I'd have to go find a stack trace and
>> figure out exactly where this but it should probably be based on a mutex so
>> it can continue immediately when the other thread operation completes.
>> Doing so will fix the bug and other future cases where it takes a long time
>> for the external action to occur as well as making it faster in situations
>> where it takes only a few ms to perform.
>>
>> On Wed, Mar 8, 2017 at 4:16 PM, Brian Burkhalter <
>> brian.burkhalter at oracle.com> wrote:
>>
>>> Hi Jon,
>>>
>>> What kind of blocking do you intend?
>>>
>>> Thanks,
>>>
>>> Brian
>>>
>>> On Mar 8, 2017, at 1:12 PM, Jon V. <sybersnake at gmail.com> wrote:
>>>
>>> It makes me uneasy that there is this kind of blocking in SocketChannel
>>> to begin with.
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170308/271b2ff1/attachment.html>