Ah I see. I like the idea, it would mean pretty comprehensive error
reporting and should work across platforms too I think.
On Tue, May 14, 2019 at 7:16 AM Florian Weimer <fwei...@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.
>
> Thanks,
> Florian
--
- DML
