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

[Thomas Stüfe]

On Tue, May 14, 2019 at 2:16 PM Florian Weimer <fweimer at redhat.com> wrote:

> * 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.
>
>
Yes.

Right now I am worried more about things I cannot determine yet. Where
before we would wait for the pipe to get broken, now we have a read call on
the parent side, a write call on the child side, which both must succeed.
Could they fail sporadically, e.g. due to EINTR? I know this sounds very
vague but around this API I am super careful.

I will also check our proprietary port. I have a deja vue, maybe I did a
similar thing already in our code base (we have an own Runtime.exec
implementation). If that is the case, this would be a proven concept and
I'd feel safer.

..Thomas


> Thanks,
> Florian
>