On Tue, 13 May 2025 12:51:56 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
>> You are right and I am confused. I always assumed that the primary function >> of jspawnhelper was to make vfork safe. Historically, that was the typical >> reason for an intermediate exec() to a helper - basically, you first exec() >> the helper as quickly as possible to get your own process memory. Then you >> do all the things you need to do in preparation for the final exec(), then >> exec again. >> >> I am surprised that this has worked with vfork() so flawlessly all this >> time. Maybe it didn't; maybe the libc's have all internally replaced vfork() >> with fork(), since fork() is fast enough nowadays. >> >> I actually don't understand why the jspawnhelper is even needed for >> posix_spawn, since all the things one does in jspawnhelper can be done also >> via posix_spawn process attributes. > > Hmm, glibc keeps it very vague in the vfork() manpage, stating that "On some > implementations, vfork() is equivalent to fork()." AIX manpage says just "The > vfork subroutine is supported as a compatibility interface for older Berkeley > Software Distribution (BSD) system programs" which sounds to me its just an > alias for fork(). MacOS has no vfork anymore. > > So maybe Solaris was the last platform with a true vfork. @tstuefe the helper was needed in part to enable a chdir between fork and exec - see this comment: https://bugs.openjdk.org/browse/JDK-5049299?focusedId=12148272&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12148272 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2087830040
