I think because the only two possible outcomes are either that the FD was not dup'd, in which case things carry on as before, or that it was dup'd, in which case (at least in the JVM) re-dupping won't really do anything harmful since the target FD already references the dead socket FD.
The POSIX manpage doesn't seem to include any other possibilities. On Mon, Jul 2, 2018 at 7:04 AM David Holmes <david.hol...@oracle.com> wrote: > > 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 > >>>> > >>> -- - DML
