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.
You *could* wait for the other end of the pipe to close (and write jspawnhelper to close the write end on exec) as an indication that the subsequent exec succeeded, while also reading from the pipe to determine if the exec has failed (writing the errno or something). Not sure if that's racy though, as I've only given it a minute of thought. On Tue, May 14, 2019 at 4:37 AM Thomas Stüfe <thomas.stu...@gmail.com> wrote: > > Neat idea! > > But this incurs costs for this pipe communication on every spawn. What do > the others think? > > Cheers, Thomas > > On Tue, May 14, 2019 at 10:22 AM Florian Weimer <fwei...@redhat.com> wrote: > > > * Thomas Stüfe: > > > > > This is impossible to fix completely - see Martin's comment about the > > > impossibility to foresee whether an exec() will succeed without actually > > > exec()ing. But at least we can test the execute permissions on the > > > jspawnhelper. Which this fix does. This fixes Ubuntu 16.4 (Now, I get an > > > IOException if jspawnhelper is not executable). > > > > I think jspawnhelper could write something to the pipe to show that it > > has started. If you never get that notification, you know that > > jspawnhelper hasn't run, even if posix_spawn has succeeded. > > > > (This fix will also help qemu-user and WSL, which implement vfork as > > fork and interfere with the internal error reporting from posix_spawn.) > > > > Thanks, > > Florian > > -- - DML
