On Mon, 30 Sep 2024 13:07:42 GMT, sbgoog <d...@openjdk.org> wrote:
>> src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line
>> 961:
>>
>>> 959: } catch(InterruptedException e) {
>>> 960: checkLockFile0ErrorCode(errorCode);
>>> 961: // Don't lose the interrupt unless we throw.
>>
>> Why should we lose the interrupted status if we throw a SecurityException?
>> It doesn't look right.
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20938#discussion_r1781168496
