RFR: 8211851: (ch) java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out (aix) [v5]

[Martin Doerr]

On Tue, 17 Dec 2024 14:57:14 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Test /jdk/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out on aix.
>> 
>> The problem is that in queueControlEvent() for every event added to the controlQueue one byte is written to the ctlSP pipe to wakeup the poll thread running in poll(). The poll() function of the poll thread is just taking this one byte from the pipe but handling then all events in the controlQueue. Afterwards the controlQueue is empty, but the pipe is only 1 byte shorter. This is an asymmetric and therefore false behavior.  So I changed the drain1() to a drain() meaning drain_all() which heals this asymmetry.
>> The problem leading to the timeout was, that more and more (StressLoopback: nomen est omen) wakeup bytes were written to the pipe, but the poll thread runs in much lower frequency. So, at some time the pipe was full on OS side, resulting in a blocking Pollset.interrupt(ctlSp[1]) in queueControlEvent(). Unfortunately, at this moment the controlQueue sync object is in locked state, resulting that the poll thread cannot acquire this lock to read from the pipe. No reading from the pipe means the pipe remains full and the dead lock is there.
>> Additionally, I found a flaw in the emulator of the ‘one shot’ semantic. Here the original implantation was not save against deleting a just registered fd before the next poll. To fix this I separated the emulation of the ‘one shot’ from the rest of the poll() actions. Now, the ‘one shot’ emulation is encapsulated in the controlLock.lock()block, which guards the poll itself.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights again

Marked as reviewed by mdoerr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22633#pullrequestreview-2512342365