std.process.Child: use clone() instead of fork()

[ruihe774]

See discussions in #1620.

This PR depends on #22341. (merged)

[ruihe774]

clone() does not work in .stage2_c. I disabled it in this case.

[ruihe774]

I use clone3() in x86 and x86_64 so that I can use CLONE_CLEAR_SIGHAND if available. I'm not familiar with (and I cannot test) asm of other ISAs. Sorry.

[ruihe774]

@alexrp PTAL.

[ruihe774]

@alexrp Is #22427 a blockade of this PR?

[alexrp]

Probably not. The workaround can be removed once that bug has been fixed.

By the way, I'm not particularly familiar with the actual process management logic in std.process.Child. Someone else should probably review that.

[ruihe774]

By the way, I'm not particularly familiar with the actual process management logic in std.process.Child. Someone else should probably review that.

@andrewrk Would you plz have a look?

[NicoElbers]

Hai there, I also wrote an implementation of clone3 (#22616), not knowing about your pr, and I have a question for you. The clone3 syscall itself is simply a fork with much more granularity (as per the man page), however what you seem to have implemented is closer to the clone glibc function using clone3 under the hood. Perhaps I'm misunderstanding, but this is not directly the syscall right?

Additionally, if it's for perfomance reasons I also don't fully understand. Looking at godbolt, the handrolled assembly is certainly better, but I personally don't see how losing 5 or so instructions offsets the additional complexity, but again perhaps I'm misunderstanding.

Would love your feedback :)

[ruihe774]

Hai there, I also wrote an implementation of clone3 (#22616), not knowing about your pr, and I have a question for you. The clone3 syscall itself is simply a fork with much more granularity (as per the man page), however what you seem to have implemented is closer to the clone glibc function using clone3 under the hood. Perhaps I'm misunderstanding, but this is not directly the syscall right?

The point is that you must use asm to perform stack switching. Yes, it's probably okay to use clone3 with stack set to null and without CLONE_VM. However, if we want to use CLONE_VM (this is the main performance benefit we can obtain from using clone3), we must set up a stack for child and using an asm wrapper to perform stack switching. We cannot write stack switching in Zig; the compiler has assumption about call frames and will mess it up.

Similar to clone, glibc also has a wrapper of clone3 to perform stack switching, though not exposed: https://github.com/bminor/glibc/blob/master/sysdeps/unix/sysv/linux/x86_64/clone3.S

[ruihe774]

Additionally, if it's for perfomance reasons I also don't fully understand. Looking at godbolt, the handrolled assembly is certainly better, but I personally don't see how losing 5 or so instructions offsets the additional complexity, but again perhaps I'm misunderstanding.

It is because you have a mistake in your code. It should be:

const rc = std.os.linux.syscall2(.clone3, @intFromPtr(args), @sizeOf(ClArgsDummy));

instead of:

const rc = std.os.linux.syscall2(.clone3, @intFromPtr(&args), @sizeOf(ClArgsDummy));

[NicoElbers]

I see, thanks a lot for your explanation. Your implementation is much more solid, and I won't have much time in the near future so I will close my PR. Good luck getting this merged :)

[ruihe774]

Any updates on this? Can we add this to some milestone? @alexrp @andrewrk