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

[Jon V.]

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/360b085a/attachment-0001.html>