On Wed, Sep 12, 2018 at 9:21 AM Martin Buchholz <marti...@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.stu...@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