Comment by josephcsible
4 years ago
When Windows and Linux each have a different way of doing a common operation, and a paper where the first author is a Microsoft employee says the Linux way was a mistake, my inclination is to be really skeptical.
4 years ago
When Windows and Linux each have a different way of doing a common operation, and a paper where the first author is a Microsoft employee says the Linux way was a mistake, my inclination is to be really skeptical.
On Darwin fork() doesn't necessarily give you a complete environment - the cloned process is essentially only intended for a few basic operations prior to calling exec()
So it isn't just windows and linux having a different way, Darwin goes its own way as well :D
That said, if you read the paper it details all the known problems of fork:
* It isn't thread safe
* It doesn't compose - every library on the address space must support fork
* It breaks basic security features - ASLR being the most obvious one, but there are sandbox issues (Darwin), pledges (BSD), capabilities (Fuchsia)
The paper also details the myriad performance problems of the API.
fork/exec is also very slow due to the need to duplicate enough OS data structures to support the forked child despite it not being useful in the general case to separate these. Even POSIX recognizes this and specifies posix_spawn() which is faster than fork/exec on all POSIX environments.
posix_spawn is just a wrapper around vfork and exec. And crucially, you have it in addition to them, not instead of them, because sometimes it can't do what you need.
An ad hominem is not a strong argument to dismiss the claim.
Did reading the paper change your opinion?
It also isn’t “the Linux way”, it’s “the Unix way”. Linux has posix_spawn now, but, reading the paper, apparently lots of tools don’t use them ¿yet?.
> An ad hominem is not a strong argument to dismiss the claim.
I'm not dismissing the claim based on it. I'm just going in skeptical since the author has an incentive for people to believe this conclusion, even if it isn't true. If a paper claims that smoking is a net benefit to your health, wouldn't you want to know that it was funded by tobacco companies?
> Did reading the paper change your opinion?
No, it didn't. Here's a few counterarguments:
* "Fork is no longer simple" - there's a lot of things you might want to do between fork and exec, and it's really not simple to have a different way to do all of them: https://lwn.net/Articles/360556/
* "Fork encourages memory overcommit" - this makes the implicit assumption that overcommit is bad, but this isn't established to be the case.
* "fork restricts the definition of a process to a single address space" - but the only difference between processes and threads is whether or not they share an address space.
* "Fork infects an entire system" - like the GPL infects an entire codebase? If something is useful, it's not necessarily a bad thing that everything will support it.
* "However, the reasons that motivated multi-process servers are long gone" - The prefork MPM isn't deprecated and there's still reasons it needs to be used sometimes today.
> Linux has posix_spawn now
posix_spawn isn't a syscall; it's a userspace function implemented by using vfork and exec internally. But if all you had were posix_spawn, there'd be no reasonable way to implement fork in terms of it, despite the fact that there are some uses for it.