Comment by kazinator

7 years ago

Fork is quite excellent, except in cases when the intent is to run a different program or when threads are involved (threads are basically an incompatible, competing model of concurrency).

The use of fork as a concurrency mechanism (creating a new thread of control that executes in a copy of the address space) is very good and useful.

In the POSIX shell language, the subshell syntax (command1; command2; ...) is easily implemented using fork. This is useful: all destructive manipulations in the subshell like assignments to variables or changing the current directory do not affect the parent.

Check out the fork-based Perl solution to the Amb task in Rosetta code: https://rosettacode.org/wiki/Amb#Using_fork

This essentially simulates continuations (in a way). (If the parent process does nothing but wait for the child to finish, fork can be used to perform speculative execution, similar to creating a continuation and immediately invoking it).

Microsoft "researchers" can stuff it and their company's flagship piece of shit OS.

11 comments

kazinator

Reply
afiori  7 years ago

The paper agrees with you that the fork models had a reason to exist and that is is perfect for shells.

They also point out that on modern hardware you often should want to write multithreaded multiprocess application.

Their main criticism of fork is that it does not compose at any level of the OS (as it cannot be implemented over a different primitive)

I understand that a lot of people here dislike Microsoft for good reason (not only historical), but drawbacks in fork() are well known and recognized, here they point out that it is also hard-to-impossible to implement as a compatibility layer if the kernel does not support fork.

Also:

> Microsoft "researchers" can stuff it and their company's flagship piece of shit OS.

Do you have any reason to insult Microsoft researchers? They have plenty of citations in this paper of other researchers that appear to agree with them. This type of comments does not appear constructive to me

  • kazinator  7 years ago

    It's an idiotic argument. Only functions compose. Though fork is packaged as a function, it's really an operator with a big effect.

    Booting a system doesn't compose; let's not have power-on reset and bootloaders.

    Everything in this paper could have been cribbed from twenty year or older Usenet postings, mailing lists and other sources. Fork has been dissected ad nausem; anyone who is anyone in the Unix-like world knows this.

    Oh, and threads have perpetually been the way to go on current hardware --- every damn year since 1988 and counting.

    • afiori  7 years ago

      Also levels of abstraction compose.

      > Booting a system doesn't compose;

      Actually this is false, virtual machine and hypervisors allow to boot a system inside another system

      5 replies →

  • kazinator  7 years ago

    > Do you have any reason to insult Microsoft researchers?

    Yes: they are pompous wankers who want to dictate not only what features people should include in their operating system, but what we should be teaching CS students.

debatem1  7 years ago

I realize that "compating" is a misspelling, but I prefer to read it as a portmanteau of "compatible" and "competing" and think it's quite an excellent word for that difficult concept except that it errs slightly too far on the "competing" side.