4 ms·

What the system call ABI that my modern operating system ought to have is not one that thinks fork() as a fundamental primitive is fit for purpose on modern com

by boricj 3y ago

What the system call ABI that my modern operating system ought to have is not one that thinks fork() as a fundamental primitive is fit for purpose on modern computers [1], for starters. Mind you, my grievances on the design and typical implementation of Unix-like operating systems go far beyond fork(), but it's as good an entry point as any for this discussion. I encourage you to read the design documents for the Fuchsia operating system, especially those for the Zircon kernel [2] for a fresh, legacy-free take on a system call interface. [1] https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... [2] https://fuchsia.dev/fuchsia-src/concepts/kernel https://fuchsia.dev/fuchsia-src/concepts/kernel

tokera 3y ago
i coded the WASIX fork syscall, so I understand all this (f.y.i. I much prefer rust to C as its got a much better designed threading system). what you must realize is that one does not have to use a syscall if they don't like it in (e.g. just use rust to code your app and it will never call the fork syscall)... but taking that choice away from others who want to use it is unfair as its denying them access to the WASM ecosystem (e.g. bash)
- boricj 3y ago
  It looks like one can easily call fork() in an unsafe block from Rust [1], assuming it's provided by the target's libc. OpenVMS for example does not provide fork(). What it does provide is vfork() by doing some internal book-keeping within the C run-time library and delaying the actual child process creation until exec() is called [2]. The POSIX specification eventually standardized posix_spawn() [3] as a partial alternative for fork() due to its numerous issues, some of which are detailed in the rationale section of its specification. Sadly, it appears its usage is not as widespread as it could be. I'm not blaming the WASIX project for providing POSIX semantics since running POSIX-compliant programs is an explicit design goal. What I do wish is that more people realize that POSIX isn't the pinnacle of operating system interface engineering or some sort of holy scripture that shall not be questioned. It's 1970s legacy from long defunct hardware and obsolete software (think PDP-11 and Version 7 Unix) that was written down as a specification in the 1980s. [1] https://docs.rs/libc/latest/libc/fn.fork.html https://docs.rs/libc/latest/libc/fn.fork.html [2] https://vmssoftware.com/docs/VSI_C_RTL_REF_MAN.pdf https://vmssoftware.com/docs/VSI_C_RTL_REF_MAN.pdf [3] https://pubs.opengroup.org/onlinepubs/9699919799/ https://pubs.opengroup.org/onlinepubs/9699919799/

by boricj 3y ago

tokera 3y ago

i coded the WASIX fork syscall, so I understand all this (f.y.i. I much prefer rust to C as its got a much better designed threading system). what you must realize is that one does not have to use a syscall if they don't like it in (e.g. just use rust to code your app and it will never call the fork syscall)... but taking that choice away from others who want to use it is unfair as its denying them access to the WASM ecosystem (e.g. bash)

boricj 3y ago
It looks like one can easily call fork() in an unsafe block from Rust [1], assuming it's provided by the target's libc. OpenVMS for example does not provide fork(). What it does provide is vfork() by doing some internal book-keeping within the C run-time library and delaying the actual child process creation until exec() is called [2]. The POSIX specification eventually standardized posix_spawn() [3] as a partial alternative for fork() due to its numerous issues, some of which are detailed in the rationale section of its specification. Sadly, it appears its usage is not as widespread as it could be. I'm not blaming the WASIX project for providing POSIX semantics since running POSIX-compliant programs is an explicit design goal. What I do wish is that more people realize that POSIX isn't the pinnacle of operating system interface engineering or some sort of holy scripture that shall not be questioned. It's 1970s legacy from long defunct hardware and obsolete software (think PDP-11 and Version 7 Unix) that was written down as a specification in the 1980s. [1] https://docs.rs/libc/latest/libc/fn.fork.html https://docs.rs/libc/latest/libc/fn.fork.html [2] https://vmssoftware.com/docs/VSI_C_RTL_REF_MAN.pdf https://vmssoftware.com/docs/VSI_C_RTL_REF_MAN.pdf [3] https://pubs.opengroup.org/onlinepubs/9699919799/ https://pubs.opengroup.org/onlinepubs/9699919799/