Code Review Request : 7011591 JDWP socket transport should restart interrupted system calls (EINTR)
david.buck at oracle.com
Thu Aug 4 05:02:23 PDT 2011
I would like to request that my fix for 7011591 be reviewed for push
into JDK8 (and JDK7u if possible).
CR: 7011591 JDWP socket transport should restart interrupted system
(for some reason, the public URL for the parent bug is not working. (I
believe that SubCR 2205030 will have all needed information.)
Syscalls that can be interrupted by signal handling should automatically
retry if they fail with EINTR. Unfortunately, the JDWP socket transport
implementation does not do this. Since HotSpot does not use signals for
thread suspension, HotSpot customers have not run into any problem (as
far as I know). But because JRockit R27 and earlier releases use signals
to suspend threads, all threads are constantly being interrupted thus
JRockit customers are much more likely (almost guaranteed under some
circumstances) to have system calls interrupted by signal handling.
I have added a loop to automatically retry send(), recv(), sendto(),
recvfrom(), accept(), and poll() calls if the call fails with EINTR.
Note that I do not believe that the UDP versions of the calls
(recvfrom() and sendto()) are actualy ever used in the JDK, but I fixed
them in case they are used in the future.
The implementation for connect() was more complicated because Solaris
does not let us just call connect() again after EINTR. Once a call to
connect() fails with EINTR on Solaris, the connection setup continues
asynchronously and we need to use select() or poll() to determine when
the socket can be used.
The patch for jdk7u2 is identical to this (jdk8) fix, if possible, I
would like to receive pre-approval to push to jdk7u-dev repository as well.
This fix has already been done for 1.4.2/5/6 as part of the JRockit
Simplification Project. This needs to be forward ported into 7 and 8 to
avoid a regression.
More information about the jdk7u-dev