Julia Evansinteresting to see that Linux might be making a new way to create processes instead of fork/exec https://lwn.net/SubscriberLink/1076018/16f01bbbb8e0d1f0/
Tristan Colgate-McFarlane@b0rk I'm old enough that I thought clone() was the new fork.
Anthony Sorace@b0rk Interesting; there’s been some push for this since at least 2019, but this does seem like the most real traction it’s gotten.
Personally, I think the fork+exec model is still better, except for how comparatively expensive fork is on Unix (compared to say Plan 9), but I’ve never seen a comprehensive analysis of how painful fixing it on unix would be (vs just creating a new syscall). Maybe linux just has too much baggage attached to fork to fix.
@b0rk If you haven’t seen it, I think this paper was the start of the mainstream push, at least as far as I saw. It makes some good points, but I think “cheap fork” is really still the better way to go.
https://www.microsoft.com/en-us/research/wp-content/uploads/2019/04/fork-hotos19.pdf
Zack Weinberg@a @b0rk I was under the impression that the cost of fork was almost entirely down to *hardware* limitations: marking an address space copy-on-write means flushing all the associated TLB entries. And then you have to do it again when the child calls execve.
Does Plan 9 have some kind of clever trick for this or does it "just" tend to use smaller processes so the costs are lower?
@zwol @b0rk The fundamental syscall in Plan 9 is rfork(), which inspired the BSD rfork() and linux’s clone(). These give a lot more control over which elements are copied vs shared. Plan 9’s fork() is rfork() with some defaults; at that level, it’s about having better defaults over what’s copied.
No magic, just different choices that ended up working better (at least in some ways).