Runtime.exec : vfork() concerns and a fix proposal

[David Lloyd]

On Wed, Sep 12, 2018 at 9:21 AM Martin Buchholz <martinrb at google.com> wrote:
>
> I agree that your proposal makes the implementation more robust, so if
> you are willing to implement it and it doesn't cost too much, then I
> would support it.  The current implementation doesn't seem to cause
> trouble in practice, or at least we don't see any bug reports.
>
> When you benchmark with open file descriptors, try with and without
> FD_CLOEXEC flag set.  Almost all fds should be created with the
> FD_CLOEXEC flag set - openjdk is moving in that direction.  When there
> are many open files, your implementation may be a weird sort of
> optimization.
>
> On Tue, Sep 11, 2018 at 10:51 AM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>
> > The point of this technique is that we minimize the window in the
> > child between vfork and the first exec. In fact, we are now fully
> > POSIX compliant.
>
> 2004-POSIX compliant ... but in the mean time they removed vfork().
> But vfork is critical for Google (and probably others)  due to the
> momentary overcommit problem on Linux.  Or has that changed somehow?

If the lack of POSIX support is a problem, posix_spawn could possibly
be used instead in this case:

> The child process is created using vfork(2) instead of fork(2) when [...] file_actions is NULL and the spawn-flags element of the attributes object pointed to by attrp does not contain POSIX_SPAWN_SETSIGMASK, POSIX_SPAWN_SETSIGDEF, POSIX_SPAWN_SETSCHEDPARAM, POSIX_SPAWN_SETSCHEDULER, POSIX_SPAWN_SETPGROUP, or POSIX_SPAWN_RESETIDS.

This would only work if the helper program is run directly though.

-- 
- DML