Hacker News Reader

Comment by lawl | Hacker News Reader

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

View on HN

It's suggesting posix_spawn, which is standardized and has nothing to do with Microsoft.

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

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?

Can't you use posix_spawn() with WSL and your favorite POSIX-compatible libc implementation?

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.

Also relevant, regarding the Linux native performance:

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

"a 100mb process generally takes >2ms to fork, while a 1mb or less process takes 70us"

Glibc got its main clone-based implementation in 2016, so it should be much more competitive now.

It's just the equivalent, not EEE.

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://docs.microsoft.com/en-us/windows/desktop/api/process... https://www.itec.suny.edu/scsys/vms/OVMSDOC073/v73/5932/5932... 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.

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

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/nma... the Smithsonian has early design docs with the original name on the spine).

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.

Reply on news.ycombinator.com