On Mon, 30 Sep 2024 13:46:55 GMT, Daniel Jeliński <djelin...@openjdk.org> wrote:
>> I thought that if an access error is found, then that would take precedence
>> over the interrupt, especially since it occurs before the sleep. I was more
>> concerned with just returning false and the caller not knowing if it's false
>> due to interrupt, or false because the file could not be locked after all
>> retries.
>>
>> Certainly the interrupt status could move before the check which may
>> through, but I think it's less likely that the status will be checked in a
>> catch of SecurityException.
>
> The status might not be explicitly checked, but setting the interrupted
> status will make sure that subsequent calls to sleep/await/tryLock etc. will
> not block.
>
> In general, we want to preserve the interrupted status until either the user
> decides that it's fine to clear, or until the thread dies.
In which case the code might be simplified to just:
} catch (InterruptedException e) {
// Don't lose the interrupt
Thread.currentThread().interrupt();
break;
}
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20938#discussion_r1781202892
