RFR: 8265261: java/nio/file/Files/InterruptCopy.java fails with java.lang.RuntimeException: Copy was not interrupted

[Brian Burkhalter]

On Wed, 18 Aug 2021 21:28:42 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> This proposal suggests to change the timing of testing whether a file copy is terminated by an interrupt.
>
> ah yes! with the count of 2 you wish to avoid either thread racing ahead, and so are attempting to arrange that the interrupter is at least Ready to Run when the copy thread initiates its copy, as such creating a reasonable probability that the interrupter will invoke the interrupt while the copy is in progress. As such,  the ping pong between the two threads is a sort of ad hoc barrier, which seems reasonable and will most likely work the majority of the time.
> 
> But there is, I think, still some probability of missing the interrupt, if the interrupter thread "got stuck" after its little sleep, and was less than fairly scheduled? This is where agentvm or othervm may have influence, depending on the scheduling algorithm of the OS. Are threads, on Windows, scheduled independent of their owning process or relative to their owning process. othervm mode, afaik, launches a new process to executed the test, not sure if that would influence the scheduling of its threads.
> 
> Would some additional diagnostic output be useful in the Interrupter thread to indicate that it starting to run and it is invoking interrupt or has invoked interrupt?
> 
> In the second phase of the test the cancellation of scheduled task, is a latch also required in this instance, to ensure that when the cancel is invoked that the copy is in progress.

@msheppar Right, the latch is intended to do exactly what you described. There is definitely still some probability of missing the interrupt however, but this results in a failure only if the copy took more than `DURATION_MAX_IN_MS` (5 seconds). I don't know how this limit was determined.

I think you are correct about the problem of the interrupter getting stuck. I don't know which vm mode would best minimize this problem.

I had some print statements in the test when I was playing around with different approaches, but I was afraid that they might affect the timing. I'll take another look at it however as well as the idea of a latch added to the cancellation section.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5154