On Tue, 13 May 2025 12:47:39 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
>> Er? This is news to me. Where do you see this? I see we only pass the
>> `helperpath` (carrying `jspawnhelper` path only to `POSIX_SPAWN` mode:
>>
>>
>> static pid_t
>> startChild(JNIEnv *env, jobject process, ChildStuff *c, const char
>> *helperpath) {
>> switch (c->mode) {
>> /* vfork(2) is deprecated on Darwin*/
>> #ifndef __APPLE__
>> case MODE_VFORK:
>> return vforkChild(c);
>> #endif
>> case MODE_FORK:
>> return forkChild(c);
>> case MODE_POSIX_SPAWN:
>> return spawnChild(env, process, c, helperpath);
>> default:
>> return -1;
>> }
>> }
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086748837
