RFR(s): 8223777: In posix_spawn mode, failing to exec() jspawnhelper does not result in an error

Florian Weimer fweimer at redhat.com
Tue May 14 12:15:59 UTC 2019


* David Lloyd:

> Pipe communication isn't very costly AFAIK.  The added complexity
> would be waiting for either a thing to appear on the pipe indicating
> success or else a waitpid/waitid+WNOHANG for exit code 127.  But
> writing a thing to the pipe won't help determine if the subsequent
> exec succeeded, which is really the interesting bit.

Please have a look at the code.  It's already using CLOEXEC to cover
the execve call (src/java.base/unix/native/libjava/ProcessImpl_md.c):

    switch (readFully(fail[0], &errnum, sizeof(errnum))) {
    case 0: break; /* Exec succeeded */
    case sizeof(errnum):
        waitpid(resultPid, NULL, 0);
        throwIOException(env, errnum, "Exec failed");
        goto Catch;
    default:
        throwIOException(env, errno, "Read failed");
        goto Catch;
    }

Instead of 0/4 bytes, the outcome could be 0/4/8 bytes, corresponding to
jspawnhelper exec failure, complete success, and exec failure in
jspawnhelper.

The run-time cost would be the additional pipe write in jspawnhelper.
There shouldn't even be another ping-pong between the processes.

Thanks,
Florian


More information about the core-libs-dev mailing list