On Fri, 27 Sep 2024 18:46:54 GMT, Daniel Jeliński <djelin...@openjdk.org> wrote:
>> FIleSystemPreferences.lockFile() catches an InterruptedException and just
>> returns false, forgetting to re-interrupt the current thread. This leaves
>> the caller with no way to observe that the thread was interrupted. This
>> change restores the interrupted status on the current thread before
>> returning.
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20938#discussion_r1781099312
