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