7133499: (fc) FileChannel.read not preempted by asynchronous close on OS X

[Chris Hegarty]

The changes in the webrev look ok to me Alan, we’ll now be using signals on all “unix” platforms.

-Chris.

On 20 Jan 2014, at 12:03, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> 
> One of the outstanding issues from the OS X port is that the async close of a FileChannel where there are threads blocked doing I/O operation does not work, instead close hang (potentially indefinitely, say when another thread is blocked waiting for a file lock to be acquired or where the file is something like a pipe or other type of file where you can block indefinitely). From what I can tell, it wasn't implemented in Apple's JDK6 either.
> 
> In order to fix this on OS X then close needs to signal all threads that are blocked in I/O operations, something we already do on Linux. The other part is removing the preClose (the dup2) from the closing of FileChannels as it is not needed when you can signal. The webrev with the proposed changes is here:
> 
> http://cr.openjdk.java.net/~alanb/7133499/webrev/
> 
> Fixing this issue means that two tests can be removed from the exclude list (there is third test removed from the exclude list too, that shouldn't have been there).
> 
> -Alan.