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

[Brian Burkhalter]

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/6ed67aaa/attachment.html>