Hi, I am currently working on child process issues and again noticed how inherently dangerous the vfork mode is.
The child process can damage or kill the parent process if bad things happen in the time window between vfork and exec, when we prepare the target binary execution. For a non-exclusive list of things that can go wrong please see my old mail from 2018 here: https://mail.openjdk.org/pipermail/core-libs-dev/2018-September/055333.html These errors are vicious too, since they would rarely be attributable to vfork; they would probably look like random crashes or libc problems. Back in 2018, I proposed an exec-twice technique whereby one execs a helper binary first to isolate the child process preparations; then do the final exec of the target binary. That is safe, fast, and it works. We can still do this. Would be wven simpler to implement now: we have the jspawnhelper and can just reuse that for vfork. However, we also could just get rid of vfork. That would simplify things alot. We have moved to posix_spawn-by-default with JDK 13 in 2019 ( https://bugs.openjdk.org/browse/JDK-8213192). That is a long time ago; probably long enough to ween all customers off vfork use. What do people think? Thanks, Thomas
