In reference to 8205959, where is it stated that dup2 is any more
restartable than close ??
AFAICS both leave things undefined/unspecified if they set EINTR.
David
On 2/07/2018 7:03 PM, Langer, Christoph wrote:
Hi Matthias,
forwarding to serviceability-dev, because debugging is usually discussed there.
Yes, I would think this coding should be fixed, too. Can you open a bug and
prepare a change?
Thanks
Christoph
-----Original Message-----
From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of
Norman Maurer
Sent: Montag, 2. Juli 2018 10:23
To: Baesken, Matthias <matthias.baes...@sap.com>
Cc: Stuefe, Thomas <thomas.stu...@sap.com>; net-dev@openjdk.java.net
Subject: Re: RFR : 8205959 : Do not restart close if errno is EINTR
+1 retry a close on EINTR has most likely not the outcome you expect and
may even close a wrong FD if the same FD is reused already (as even if EINTR
is returned it may have closed the FD)
Am 02.07.2018 um 10:17 schrieb Baesken, Matthias
<matthias.baes...@sap.com>:
Hello , there is a similar pattern (attempt to restart close in case of EINTR)
in the coding as well in socket_md.c :
src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c-147- int rv;
src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c-148- do {
src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c-149- rv =
close(fd);
src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c:150: } while (rv
== -1 && errno == EINTR);
src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c-151-
src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c-152- return rv;
src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c-153-}
Do you think this needs adjustment (on LINUX) as well ?
Best regards, Matthias
Message: 2
Date: Thu, 28 Jun 2018 18:19:46 +0100
From: Alan Bateman <alan.bate...@oracle.com>
To: David Lloyd <david.ll...@redhat.com>, ivan.gerasi...@oracle.com
Cc: OpenJDK Network Dev list <net-dev@openjdk.java.net>
Subject: Re: RFR : 8205959 : Do not restart close if errno is EINTR
Message-ID: <3fd1496f-ab83-a2d5-0699-13c8b735d...@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 28/06/2018 17:35, David Lloyd wrote:
:
Do you (or Alan) think that this might have accounted for real-world
connection problems?
In the file I/O area, with NFS I think, we had an issue a long time ago
where close was retried after EIO. That issue was fixed a long time ago
but it's one that comes to mind in this general area.
-Alan