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 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//'" 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 >