Runtime.exec : vfork() concerns and a fix proposal
david.lloyd at redhat.com
Wed Sep 12 14:33:09 UTC 2018
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
> 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.
More information about the core-libs-dev