On 15/03/2019 06:43, David Holmes wrote:
Yes and on closer examination you will find a lot of inconsistencies.
RESTARTABLE goes back a long way and many of the I/O APIs have
switched locations over the years. Stuff was copied from the HPI layer
into hotspot, then back to the JDK and sometimes things were copied
with RESTARTABLE and sometimes not; and sometimes ports were written
that copied RESTARTABLE and sometimes not; and sometime new APIs were
added that were RESTARTABLE and sometimes not. All in all a bit of a
mess.
For example here are some uses of write in JDK libs:
./share/native/libzip/zlib/gzwrite.c: writ =
write(state->fd, state->x.next, put);
./unix/native/libnio/ch/IOUtil.c: return convertReturnVal(env,
write(fd, &c, 1), JNI_FALSE);
./unix/native/libnio/ch/FileDispatcherImpl.c: return
convertReturnVal(env, write(fd, buf, len), JNI_FALSE);
./unix/native/libnio/fs/UnixCopyFile.c: RESTARTABLE(write((int)dst,
bufp, len), n);
./unix/native/libnio/fs/UnixNativeDispatcher.c:
RESTARTABLE(write((int)fd, bufp, (size_t)nbytes), n)
./unix/native/libjava/ProcessImpl_md.c: write(c->childenv[1], (char
*)&magic, sizeof(magic)); // magic number first
./unix/native/libjava/io_util_md.c: RESTARTABLE(write(fd, buf,
len), result);
A mix of RESTARTABLE and not.
Some of these are in the native methods in the implementation of APIs
that support for async close and where a signal is used to interrupt
blocking calls. For those cases, the retry is done in the Java code.
I think Ivan's patch looks okay but I think you are right with your
general point that something else must be going on if we are running
into this now. It would require native code or a bug something to have
these system calls falling with EINTR. At some point we need to replace
the UnixFileSystem implementation too but that is for another discussion.
-Alan
