For what it's worth, I've looked at the code and the CSR and I think where this
has ended up is fine.
Phil had previously raised some concerns about the change in behavior. I think
those are reasonable concerns; obviously I don't know about every place
Robot.delay() is used that could possibly be affected. However, I believe the
change makes its interrupt handling more reasonable.
Interrupts don't come out of nowhere; if this thread is interrupted, then
whoever sent the interrupt wants this thread to stop what it's doing. In the old
code, the sleep() would return, but the interrupt status would be cleared, and
the thread would continue doing whatever it was doing. Effectively, the
interrupt would be ignored!
In the new code, sleep() will return immediately, and delay() will leave the
interrupt status set. This is the right thing; we want it to affect subsequent
code, including subsequent calls to Robot.delay(). We want those delays to be
skipped, instead of further delaying the handling of the interrupt. Eventually
something will cause InterruptedException to be thrown, stopping this thread's
activities, which is what the interrupter wanted.
s'marks
On 12/5/19 4:53 PM, Sergey Bylokhov wrote:
Any volunteers to review? =)
On 10/31/19 5:04 pm, Sergey Bylokhov wrote:
Hello.
Please review an updated version of the fix for jdk14.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210231
CSR: https://bugs.openjdk.java.net/browse/JDK-8230783
Fix: http://cr.openjdk.java.net/~serb/8210231/webrev.03
The logic of the method is skipped if the thread was interrupted already.
