RFR: 8339850: Restore the interrupt status in FileSystemPreferences.lockFile()

[sbgoog]

On Fri, 27 Sep 2024 18:46:54 GMT, Daniel Jeliński <djelinski at 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