It's a measure of Unix having been wounded by its own success.
fork() is a great model for a single-threaded text processing pipeline to do automated typesetting. (More generally, anything that is a straightforward composition of filter/transform stages.) Which is, y'know, what Unix is *for*.
fork() dates from a time that demand paging wasn't a thing. Processes were as cheap as it got. There were no threads.
All the different variations on a theme on fork() since then have been to either make threads super cheap to create, to optimize the exec case (which already has been discussed a bit:), and/or to control what the new process inherits.
It's not so great for a responsive GUI in front of a multi-function interactive program.
These days, the vast majority of Unix applications are "stuff people play with on their phones."
Ah, a thread-heavy environment that's not all that exec intensive (but that's complicated enough you can no longer safely do a naive fork/exec when you need to)...
But mostly, it's threads.
Warner
On Mon, Aug 2, 2021 at 7:59 AM Theodore Ts'o <
tytso@mit.edu> wrote:
On Sun, Aug 01, 2021 at 10:42:53PM -0400, Douglas McIlroy wrote:
> > spawn() beats fork()[;] fork() should be deprecated
>
> Spawn is a further complication of exec, which tells what signals and
> file descriptors to inherit in addition to what arguments and
> environment variables to pass.
>
> Fork has a place. For example, Program 1 in
> www.cs.dartmouth.edu/~doug/sieve/sieve.pdf forks like crazy and never
> execs. To use spawn, the program would have to be split in three (or
> be passed a switch setting).
>
> While you may dismiss Program 1 as merely a neat demo, the same idea
> applies in parallelizing code for use in a multiprocessor world.
It's certainly clear that some kind of primitive is needed to create
new threads. An open question is whether if there exists some kind of
"new thread" primitve plus either spawn(2) or some kind of "create a
child process and then then frob like crazy using 'echo XXX >
/proc/<pid>/<magic files>'" whether there still is a need for a
fork(2) system call.
Obviously, as soon as we start going down this path, we're deviated
quite strongly from the "radical simplicity" of Unix Version 7 that
people have accused modern systems (whether they be Linux or FreeBSD)
of lacking. It's rather interesting that we haven't heard complaints
about how people who dare to try come up with new API's are somehow
traitors to "The Unix Philosphy" that we've seen on other threads. :-)
- Ted