You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since this is about POSIX and the browser, crucial question is - what is meant by that?
POSIX is in the first place an OS design specification, that describes several interfaces and concepts on different levels (from typical kernel C interfaces, some userland definitions baked into C libs up to high level interaction paradigms like shell env).
From a C programmers perspective POSIX compliance means, that as long as the system provides the POSIX subset (by a clib and a suitable compiler), my program still compiles and runs as expected.
From a kernel programmers perspective it means, the kernel has to implement certain interfaces a C-lib can hook into, like processes, threads, file IO, socket, pipes, privilege system, terminal - and all with a certain behavior.
A userland programmer from other POSIX systems will feel familiar with the env, given his language was ported as well.
Finally for the user it means, he gets all the beloved or hated terminal tools and the Unix way to solve things.
Urgh, thats already quite much and not even going into any details. One word at start - a fully-fledge POSIX env seems quite impossible to me in a browser without CPU emulation. Going down to CPU emulation gives you all the freedom to shape things as you wish, but will suck hard on resources (prolly making things unusable in the end). To me a more interesting question is - is it possible to give up some expectations from above and build something closely POSIX-related with interfaces, that the browser already ships with?
Whats already there?
emscripten has done a great job bringing C to the browser. It ships with a custom libc with tons of POSIX shims. Def. a good starting point to get the C programmer from above satisfied.
WASM The new shiny gem for binaries and browsers. They also build on certain interfaces (WASI). emscripten already transited to wasm. Note both mainly aim for single executable stack, thus no process control yet possible. Which points to a big showstopper, what about a kernel?
Regarding a kernel like shim the best I could find is browsix. Everything else with serious efforts into that direction is again emulation based, and there is a reason for this. The browser env (with JS/WASM/worker threads) simply cannot efficiently mimick certain kernel tasks, like process fork/exec, or interrupting of running tasks. What sounds like a minor nasty side effect is really a big showstopper - you simply cannot put some task into a kernel like guard role, which puts the whole idea of preemptive multitasking in POSIX on trial, it also introduces big performance issues in emscripten, since blocking actions have to be shimmed with expensive stack forth and back unrolling. Note that also WASM does not allow this, they left this out by purpose (propagating non-blocking code rewrites).
I kinda stumbled into the kernel issues myself with my playground project https://github.com/jerch/browser-fakepty. It is just trying to get some familiar terminal concepts ported (mimicking a pty), but it already pulls in tons of POSIX primitives. For the things I want to get working there I decided to stay in cooperative multitasking with JS, and wrote a few test "programs". (Did not push there in a while, still stuck on the TTY rewrite with job control and binary pipes.)
The text was updated successfully, but these errors were encountered:
Since this is about POSIX and the browser, crucial question is - what is meant by that?
POSIX is in the first place an OS design specification, that describes several interfaces and concepts on different levels (from typical kernel C interfaces, some userland definitions baked into C libs up to high level interaction paradigms like shell env).
From a C programmers perspective POSIX compliance means, that as long as the system provides the POSIX subset (by a clib and a suitable compiler), my program still compiles and runs as expected.
From a kernel programmers perspective it means, the kernel has to implement certain interfaces a C-lib can hook into, like processes, threads, file IO, socket, pipes, privilege system, terminal - and all with a certain behavior.
A userland programmer from other POSIX systems will feel familiar with the env, given his language was ported as well.
Finally for the user it means, he gets all the beloved or hated terminal tools and the Unix way to solve things.
Urgh, thats already quite much and not even going into any details. One word at start - a fully-fledge POSIX env seems quite impossible to me in a browser without CPU emulation. Going down to CPU emulation gives you all the freedom to shape things as you wish, but will suck hard on resources (prolly making things unusable in the end). To me a more interesting question is - is it possible to give up some expectations from above and build something closely POSIX-related with interfaces, that the browser already ships with?
Whats already there?
Regarding a kernel like shim the best I could find is browsix. Everything else with serious efforts into that direction is again emulation based, and there is a reason for this. The browser env (with JS/WASM/worker threads) simply cannot efficiently mimick certain kernel tasks, like process fork/exec, or interrupting of running tasks. What sounds like a minor nasty side effect is really a big showstopper - you simply cannot put some task into a kernel like guard role, which puts the whole idea of preemptive multitasking in POSIX on trial, it also introduces big performance issues in emscripten, since blocking actions have to be shimmed with expensive stack forth and back unrolling. Note that also WASM does not allow this, they left this out by purpose (propagating non-blocking code rewrites).
I kinda stumbled into the kernel issues myself with my playground project https://github.com/jerch/browser-fakepty. It is just trying to get some familiar terminal concepts ported (mimicking a pty), but it already pulls in tons of POSIX primitives. For the things I want to get working there I decided to stay in cooperative multitasking with JS, and wrote a few test "programs". (Did not push there in a while, still stuck on the TTY rewrite with job control and binary pipes.)
The text was updated successfully, but these errors were encountered: