Hi David,
How does your proposal differ from the current posix_spawn and
jspawnhelper MODE_POSIX_SPAWN
implementation available on Solaris and AIX?
This area is sensitive enough that it would be prudent to implement it
as a new mode in ProcessImpl/ProcessImpl; retaining the existing options.
Changing the default could be a build option and would require extensive
testing and a long stability period.
Regards, Roger
On 9/12/18 10:33 AM, David Lloyd wrote:
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.
