Re: [TUHS] Systematic approach to command-line interfaces

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]

On Mon, Aug 2, 2021 at 12:16 PM Adam Thornton <athornton@gmail.com> wrote:

> 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


> Adam
>
> 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
>>
>

[-- Attachment #2: Type: text/html, Size: 4253 bytes --]