2 Aug
2021
2 Aug
'21
8:15 p.m.
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*.
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."
Adam
On Mon, Aug 2, 2021 at 7:59 AM Theodore Ts'o <tytso(a)mit.edu> wrote:
On Sun, Aug 01, 2021 at 10:42:53PM -0400, Douglas
McIlroy wrote:
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
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.