Hacker News Reader

Comment by the_duke | Hacker News Reader

So, how does it actually work? The dedicated section on the page is not very informative.

We use Web Workers as the basis for our processes, and processes perform system calls to the kernel (running on the main browser thread). Our standard system call mechanism is asynchronous and uses the standard postMessage API to/from Web Workers. When executing a system call, the language runtime saves the current call stack, and when the Web Worker gets a response to the system call, it resumes that thread.

So we build these low-level primitives (kernel, system calls, processes) on top of APIs the browser provides, and extend to-JS compilers + runtimes to use these primitives.

Various languages can be compiled to JS, e.g. C/C++ using emscripten. This project implemented POSIX/Linux APIs in JS using browser features, so now you can compile applications that depend on those APIs to JS and run them in the browser. At least that's what I got from skimming the paper.

That still doesn't explain how syscalls are exposed as webworkers without a modified browser.

They don't expose syscalls, they implemented replacements for them. There is no access to anything outside the browser environment. Web Workers simulate processes, file system calls access a virtual file system etc.

They aren't real syscalls. From the looks of it this is essentially a mock POSIX-ish "os" for containing webassembly-compiled applications.

What will be interesting is to see if anyone ever gets to implementing X11 emulation.

technical paper is online: https://arxiv.org/abs/1611.07862

Reply on news.ycombinator.com