3 ms·

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

• detaro 10y ago
  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.
  • the_duke 10y ago
    That still doesn't explain how syscalls are exposed as webworkers without a modified browser.
    • detaro 10y ago
      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.
    • ris 10y ago
      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.
• pgbovine 10y ago
  technical paper is online: https://arxiv.org/abs/1611.07862 https://arxiv.org/abs/1611.07862
• nteon 10y ago
  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.