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

[Daniel Jeliński]

On Mon, 30 Sep 2024 13:07:42 GMT, sbgoog <duke at 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