Hi Alan,
Reordering preClose() in AIX resolves the customer issue. We have validated the
fix, and the customer has confirmed it as well.
Thanks
Shruthi
________________________________
From: Alan Bateman <alan.bate...@oracle.com>
Sent: Thursday, February 13, 2025 10:20 PM
To: Shruthi . <shruthi.shrut...@ibm.com>; net-dev@openjdk.org
<net-dev@openjdk.org>
Cc: Syed Moinudeen <smoin...@in.ibm.com>
Subject: [EXTERNAL] Re: Suggestion needed to port the fix to JDK17 and JDK11
On 12/02/2025 06: 13, Shruthi . wrote: We discussed the issue with AIX OS team
to get their input as this issue is happening only in AIX platform. Update from
AIX OS dev team: A thread gets stuck in dup2() while duplicating a file
descriptor
On 12/02/2025 06:13, Shruthi . wrote:
We discussed the issue with AIX OS team to get their input as this issue is
happening only in AIX platform. Update from AIX OS dev team: A thread gets
stuck in dup2() while duplicating a file descriptor that is already being used
by two other threads (one for reading, one for writing). The writer thread does
not write or close the FIFO, causing the reader to wait indefinitely, which
blocks dup2(). Also he is saying that we cannot change OS side as it may break
or change its existing behavior which other existing applications may be
depending on.
Can we apply the previously proposed fix at java level(reordering the
preClose() method) while adding an AIX-specific check to ensure it doesn’t
affect other platforms? Or do you have any alternative suggestions?
if (!tryClose()) {
long th = thread;
if (th != 0) {
if (!AIX.isAIX)
nd.preClose(fd);
NativeThread.signal(th);
if (AIX.isAIX)
nd.preClose(fd);
}
}
Are you sure this really fixes the issue on AIX? It means a reader or writer
may be signalled before the syscall, is the signal missed or are you saying
that it queues up on AIX? If it missed then the close will block in dup2 as
before.
-Alan
