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