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


Reply via email to