> I think WASI and WASIX is an EXTREMELY important API for the future of computing. It's a chance to create a superior operating system runtime interface.
Superior operating system runtime interface and POSIX don't rhyme. The fossilization of POSIX on Unix-like systems, endlessly piling stuff on top of that creaky foundation is probably the single biggest issue holding back the future of computing.
WASIX is probably a pragmatic design if you want to run your existing Unix programs on top of WASM. If anything, it's for the past of computing.
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.
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)
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.
Superior operating system runtime interface and POSIX don't rhyme. The fossilization of POSIX on Unix-like systems, endlessly piling stuff on top of that creaky foundation is probably the single biggest issue holding back the future of computing.
WASIX is probably a pragmatic design if you want to run your existing Unix programs on top of WASM. If anything, it's for the past of computing.