| commit | 78fab5d4a5877d161d9bf27d968c71190cb1cd81 | [log] [tgz] |
|---|---|---|
| author | Sam Clegg <[email protected]> | Sun Aug 15 14:48:44 2021 |
| committer | Sam Clegg <[email protected]> | Mon Aug 16 02:40:46 2021 |
| tree | d032a78aa8cd57453c557c3f09761f907543a2a0 | |
| parent | 7c8be3dab1218d74c0081636e2321febdacda43f [diff] |
Remove incorrect/non-working (and used?) implementation of pthread_kill Our implementation of `pthread_kill` seems to be based on the assumption that this function is supposed to kill and given thread. This is not true. Instead `pthread_kill` works more like `kill` in that is delivers and async signal to a given thread. There are many such signals available such as SIGUSR1, SIGUSR2, SIGKILL, and SIGTERM. All that pthread_kill does that is different from `kill` is that it enables the caller to decided which thread the signal handler should run in. There is no signal that can sent that reults in a termination of a given thread. Sending SIGKILL (which is unblockable) will still bring down the entire program. There is no pthread API for asynronously killing a single thread, only pthread_cancel, which requires some cooperation from the thread being terminated. The currently implementation of `pthread_kill` is based on `worker.terminate()`, which will kill the worker even if it is in a busy loop (how does this work at the OS level I wonder?), is problematic becuse the thread has no way to clean up or free resources which can lead to memory leaks. Finally, `pthread_kill` does not currently work under chrome (brings down the entire tab) so this leads me to believe that it is very unlikely anyone is relying on the feature. Fixes: #14872
Main project page: https://emscripten.org
GitHub CI status: 
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.