[WasmFS] Add an async constructor for the OPFS backend When pthreads are enabled, the existing OPFS backend constructor synchronously waits for a worker thread to start up and become ready to receive work. Since the process of starting the worker thread requires the main thread to return to its event loop, calling the constructor on the main thread would deadlock. The previous workaround was to simply not call the constructor on the main thread. As a more elegant solution, add an async version of the constructor that returns an em_promise_t that will be fulfilled with the backend handle once the worker thread has started up. This async constructor can be safely called from the main thread; the promise simply won't be fulfilled until the main thread gets a chance to return to its event loop. Internally, the new constructor works by having the worker thread asynchronously proxy a task back to the constructing thread when it is ready to receive work. The task resolves a promise on the constructing thread, which leads to the user-visible promise getting fulfilled with the value of the backend handle. Add tests using the new constructor in a fully asynchronous way using pthreads or JSPI as well as tests that use JSPI to await the result of the constructor with and without pthreads enabled.
Main project page: https://emscripten.org
Chromium builder status: emscripten-releases
Emscripten compiles C and C++ to WebAssembly using LLVM and Binaryen. Emscripten output can run on the Web, in Node.js, and in wasm runtimes.
Emscripten provides Web support for popular portable APIs such as OpenGL and SDL2, allowing complex graphical native applications to be ported, such as the Unity game engine and Google Earth. It can probably port your codebase, too!
While Emscripten mostly focuses on compiling C and C++ using Clang, it can be integrated with other LLVM-using compilers (for example, Rust has Emscripten integration, with the wasm32-unknown-emscripten and asmjs-unknown-emscripten targets).
Emscripten is available under 2 licenses, the MIT license and the University of Illinois/NCSA Open Source License.
Both are permissive open source licenses, with little if any practical difference between them.
The reason for offering both is that (1) the MIT license is well-known and suitable for a compiler toolchain, while (2) LLVM‘s original license, the University of Illinois/NCSA Open Source License, was also offered to allow Emscripten’s code to be integrated upstream into LLVM. The second reason became less important after Emscripten switched to the LLVM wasm backend, at which point there isn't any code we expect to move back and forth between the projects; also, LLVM relicensed to Apache 2.0 + exceptions meanwhile. In practice you can just consider Emscripten as MIT licensed (which allows you to do pretty much anything you want with a compiler, including commercial and non-commercial use).
See LICENSE for the full content of the licenses.