approved.
Alan Bateman wrote:
Sherman, this is your locky day :-)
6543863: (fc) FileLock.release can deadlock with FileChannel.close
This is a long-standing deadlock (since 1.4) that can happen when
closing a FileChannel and releasing a FileLock (obtained from the
channel) at around the same time. Closing locks the FileLock while
synchronized on the list of file locks; Release locks the list while
holding the FileLock. The cycle is broken by changing the removeAll
method to remove and return the list of the channel's file locks.
6429910: (fc) FileChannel.lock() IOException: Bad file number, not
AsynchronousCloseException
If the FileChannel#lock method is blocked waiting to acquire a lock on
the channel's file and the FileChannel is closed then the lock method
fails with IOException "Bad file number" whereas it is should throw
AsynchronousCloseException. The end method, marking the end of the I/O
operation was being invoked with true instead of false and so wasn't
suppressing the I/O operation.
6814948: (fc) test/java/nio/channels/AsynchronousFileChannel/Lock.java
failed intermittently
The asynchronous close sub-test fails intermittently (about 1 per 1000
runs on the machines I tried). It's a timing issue that arises if the
preclose is done before the lock attempt, in which case it will appear
the file has been acquired (but the channel is closed). The lock and
tryLock methods were missing an isOpen check.
6822643: (fc) AsynchronousFileChannel.close does not invalidate FileLocks
This is an embarrassing one. The close method attempts to release and
invalidate all locks but the "shared" FileLockTable removeAll
implementation checked the lock's channel using lock.channel() instead
of lock.acquiredBy() (and hence only worked for FileChannel).
The webrev is here:
http://cr.openjdk.java.net/~alanb/6543863%2b6429910%2b6814948%2b6822643/webrev.00/
Thanks,
Alan.
