Recent searches
Search options
Great example of Fork Considered Harmful just came up on #musl: a program that spawns children via fork+exec spending inordinate time in kernelspace (accounted as minor page faults) slowing down computation.
What happens is that, when a process forks, all of its memory gets converted to copy-on-write (CoW) which is just changes to the mapping records/page tables, not actual copying. If the child writes to any of that before exec'ing or exiting, it'll get actually duplicated, but normally folks think of this as low-cost if the child quickly execs and doesn't touch much memory...
However, even if the child never touches any of it, it's still left in a state where the pages are read-only in the parent and fault on the next write access, only for the kernel to recognize that they're not longer shared with any other task that could need them for copy-on-write and convert them back to private writable. If there's a lot of memory being accessed, that's a lot (one per page) of costly switches in and out of kernelspace.
The right solution here is not to use fork, to consider it deprecated and pretend it doesn't exist, and to use something like posix_spawn (imperfect but sufficient, at least with shims) that never makes the process's memory pass through a copy-on-write state. This also makes one's program compatible with MMU-less machines and operating systems (Windows 
) where implementing fork is extremely difficult or impossible.
@dalias or un-deprecate vfork...
@hyc There are even bigger reasons it's Considered Harmful.
@dalias and yet that is exactly what's used to implement posix_spawn(). Obviously a vfork-like syscall is still needed since posix_spawn() is only a user level library function. https://ewontfix.com/7/
@hyc The problem is that the returns-twice property of vfork cannot be made safe even against existing compiler transformations, and that there's no reasonable way to specify what functions (other than none at all) are safe to call from a vfork context.
@hyc But as you quoted my old post on it, you can read the other problems there. 
@dalias nah. The shell has tons of things to do between a fork and a possible exec (sometimes not even that but it’ll just run a builtin then exit).
But then, the shell is also rather tied to nōn-MMU-less Unix, and that model may work for less intricate programs.
@mirabilos That's an implementation choice, a classic one that easily gets the required semantics but that's not compatible with no-MMU. You can choose not to do it that way, but such a change is not really something you can retrofit without a near complete rewrite.
@mirabilos The way you do a forkless shell is not to mess with the file descriptor numbers, env vars, etc. in the shell process itself but have a data model for them, which you then marshall into spawned (not forked) subshell processes and use to setup spawn attributes and env arrays for commanded processes.
@dalias yeah, that’d make it work for nommu but it needs a completelt different design, and it’s no good fit for a featureful shell on regular unix
@mirabilos Whether it's a good fit is more a matter of philosophy than wanted features.
@dalias depends. Just don’t deprecate fork.