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:[email protected]] On Behalf Of
Norman Maurer
Sent: Montag, 2. Juli 2018 10:23
To: Baesken, Matthias <[email protected]>
Cc: Stuefe, Thomas <[email protected]>; [email protected]
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
<[email protected]>:
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 <[email protected]>
To: David Lloyd <[email protected]>, [email protected]
Cc: OpenJDK Network Dev list <[email protected]>
Subject: Re: RFR : 8205959 : Do not restart close if errno is EINTR
Message-ID: <[email protected]>
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
