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

[Alan Bateman]

On 21/01/2014 17:49, Volker Simonis wrote:
> :
> I also think they will hang, but I'm not sure how to test it. The
> java/nio/channels/AsynchronousServerSocketChannel and
> java/nio/channels/AsynchronousSocketChannel all pass, but I'm not sure
> if they test the same thing.
>
> In the NIO are, I currently (with your change) have problems with the
> following tests:
>
> java/nio/channels/AsyncCloseAndInterrupt.java (hangs)
> java/nio/channels/AsynchronousChannelGroup/Basic.java (hangs somtimes)
> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java (hangs)
> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (hangs somtimes)
> java/nio/channels/Selector/RacyDeregister.java (fails)
>
> However, java/nio/channels/AsynchronousChannelGroup/Unbounded.java
> hangs in AixPollPort.pollset_poll() (which is our implementation of
> AsynchronousChannelGroup) so that may be a completely different
> problem. I'm currently try to debug it.
The SelectableChannel and AsynchronousChannel implementations are very 
different.

In the SelectableChannel implementations then closing is complicated due 
to the possibility of threads being blocked in I/O operations. From the 
mails then it is clear that AIX hangs in dup2 but an alternative 
approach to initially signal the blocked threads should work there. One 
of the reasons for not agreeing to the calling into the NET_* function 
is that it results in double accounting, the selectable channels already 
track it. I'll send a patch soon to try and we can see about resolving 
this once the changes are in jdk9/dev. On testing it then 
AsyncCloseAndInterrupt will close and interrupt on each of the channels 
so it is a useful test.

I don't know what to say about the AsynchronousChannelGroup tests that 
are hanging, I think I'd need to see the full stack trace. Closing of 
these channels is cooperative as there isn't any blocking so it's much 
simpler. So is portset_poll your implementation of Port.startPoll?

> :
> Yes, that's no problem. I think the class library for AIX will be fine
> and ready for integration into jdk9/dev without these changes. We can
> fix that later and backport it to 8u-dev as required.
I think this makes sense.

-Alan.