4 ms·

I havent read the entire thing yet, but reading from "replacing fork" to the end it reads too much like embrace extend extinguish.

• saagarjha 8y ago
  It's suggesting posix_spawn, which is standardized and has nothing to do with Microsoft.
  • lawl 8y ago
    > Just as a programming course would not today begin with goto, we suggest teaching either posix_spawn() or CreateProcess(), and then introducing fork as a special case with its historic context (§2). Or CreateProcess(), which has a lot to do with microsoft.
    • saagarjha 8y ago
      Yeah, if you're using Windows you aren't going to be able to use it. Or are you suggesting that Microsoft should implement posix_spawn?
      • deleted 8y ago
        [deleted]
      • tomjakubowski 8y ago
        Can't you use posix_spawn() with WSL and your favorite POSIX-compatible libc implementation?
        • Dylan16807 8y ago
          Well that's a complicated question to answer. You can use the posix_spawn function in glibc, which uses a vfork or clone syscall just like on Linux.
          • acqq 8y ago
            Also relevant, regarding the Linux native performance: https://mobile.twitter.com/RichFelker/status/602313979894038528 https://mobile.twitter.com/RichFelker/status/602313979894038... "Rich Felker, May 24, 2015: Some interesting preliminary timing of @musllibc 's posix_spawn vs fork+exec shows it ~25x faster for large parent processes. (~360us vs 9ms). #glibc has a vfork-based posix_spawn but it's only usable for trivial cases; others use fork. @musllibc posix_spawn always uses CLONE_VM. This also means @musllibc posix_spawn will fill the fork gap on NOMMU systems cleanly/safely (unlike vfork) once we get NOMMU working." Also evilotto's post here: https://news.ycombinator.com/item?id=19622477 https://news.ycombinator.com/item?id=19622477 "a 100mb process generally takes >2ms to fork, while a 1mb or less process takes 70us"
            • Dylan16807 8y ago
              Glibc got its main clone-based implementation in 2016, so it should be much more competitive now.
            • JdeBP 8y ago
              See also https://news.ycombinator.com/item?id=18073906 https://news.ycombinator.com/item?id=18073906 .
    • Dylan16807 8y ago
      It's just the equivalent, not EEE.
    • saxonww 8y ago
      It really doesn't. Microsoft employs a guy named Dave Cutler who is credited with leading the development of Windows NT in the late 80s/early 90s. They hired him from DEC, where he... is credited with co-leading a research project that later became VMS. If you go look at OpenVMS programming manuals, you will see process creation calls (e.g. SYS$CREPRC, LIB$SPAWN) that look and behave a lot like CreateProcess(). I think it's well-known that Windows NT took a lot of ideas from VMS. https://en.wikipedia.org/wiki/Dave_Cutler https://en.wikipedia.org/wiki/Dave_Cutler https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createprocessa https://docs.microsoft.com/en-us/windows/desktop/api/process... https://www.itec.suny.edu/scsys/vms/OVMSDOC073/v73/5932/5932pro_042.html https://www.itec.suny.edu/scsys/vms/OVMSDOC073/v73/5932/5932... http://www.itec.suny.edu/scsys/vms/OVMSDOC073/v73/5841/5841pro_004.html http://www.itec.suny.edu/scsys/vms/OVMSDOC073/v73/5841/5841p... I don't think we should ever forget how MS behaved through the mid 2000s. But we don't live in that world anymore, they aren't (capable of being) that company anymore, and I think we're at a point where dismissing research because of a connection to MS is not protecting anyone from anything.
      • evilotto 8y ago
        > I think it's well-known that Windows NT took a lot of ideas from VMS. Has the old theory that "Windows NT" aka "WNT" = "VMS + 1" ever been proved or disproved?
        • fredoralive 8y ago
          The fact it was called "NT OS/2" before Windows NT seems to indicate it was a happy accident. (https://americanhistory.si.edu/collections/search/object/nmah_742559 https://americanhistory.si.edu/collections/search/object/nma... the Smithsonian has early design docs with the original name on the spine).
• eesmith 8y ago
  Nowhere there did the authors "embrace" fork(). Quite the contrary. While the article points out that the NT kernel natively supports fork, it certainly isn't arguing for any extension of the call. So all we're left with is "extinguish", which this article certainly does. And it is persuasive. I will look at posix_spawn() for my own code in the future.