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

Alan Bateman Alan.Bateman at oracle.com
Mon Jan 20 13:34:18 PST 2014


On 20/01/2014 19:57, Volker Simonis wrote:
> Hi Alan,
>
> I've tried your patch with our port on AIX.
> The good news is that it fixes:
>
> java/nio/channels/AsynchronousFileChannel/Lock.java
>
> on AIX as well.
>
> The bad news is, that it doesn't seem to help for:
>
> java/nio/channels/AsyncCloseAndInterrupt.java
>
> Here's a stack trace of where the VM gets stuck:
In these stack traces then the channels are Pipe.SourceChannel or 
Pipe.SinkChannel where the file descriptor is to one end of a pipe. Are 
these the only cases where you see these hangs? I'm interested to know 
if the async close of SocketChannel and ServerSocketChannel when 
configured blocked also hangs (I will guess that it will as the behavior 
is likely to be the same as pipe).

I have an idea on how to fix this so that the preClose isn't used when 
the channel is configured blocking (or isn't registered with a 
Selector). The patch doesn't use NativeThreadSet because it isn't 
efficient when the number of threads is limited to 1 or 2 (FileChannel 
uses NativeThreadSet because it defines positional read/write and so the 
number of concurrent reader/writers is unlimited).

I'll send a patch the other channels soon and we can see if this works 
for you. If it does work then I have a bit of a preference to being it 
in via jdk9/dev rather than via the AIX staging forest because the 
changes impact all platforms. That said, if we being this FileChannel 
fix for OSX in then it means that the platform specific changes would be 
in, the patch for the other platforms shouldn't require porting.

-Alan.



More information about the nio-dev mailing list