Update documentation on Wasm Workers #21686
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…Emscripten Workers API. Addresses emscripten-core#21610.
sbc100
reviewed
Apr 3, 2024
|
|
||
| Since WebAssembly does not support virtual memory, the size of the LLVM data stack that is defined both for Wasm Workers but also the main thread will not be possible to grow at runtime. So if the Worker (or the main thread) runs out of stack space, the program behavior will be undefined. Use the Emscripten linker flag -sSTACK_OVERFLOW_CHECK=2 to emit runtime stack overflow checks into the program code to detect these situations during development. | ||
|
|
||
| Note that a stack overflow in this LLVM data stack does not imply stack overflow security vulnerabilities in the WebAssembly VM. The Wasm VM program flow stack is separate from this LLVM data stack, and guarded from access from Wasm code. However, if your threat model consists of executing untrusted program code, or executing a program from untrusted input inside the WebAssembly module, you may need to consider your security model to include safekeeping the LLVM data stack as well. |
There was a problem hiding this comment.
/program flow/control flow/
|
|
||
| Since WebAssembly does not support virtual memory, the size of the LLVM data stack that is defined both for Wasm Workers but also the main thread will not be possible to grow at runtime. So if the Worker (or the main thread) runs out of stack space, the program behavior will be undefined. Use the Emscripten linker flag -sSTACK_OVERFLOW_CHECK=2 to emit runtime stack overflow checks into the program code to detect these situations during development. | ||
|
|
||
| Note that a stack overflow in this LLVM data stack does not imply stack overflow security vulnerabilities in the WebAssembly VM. The Wasm VM program flow stack is separate from this LLVM data stack, and guarded from access from Wasm code. However, if your threat model consists of executing untrusted program code, or executing a program from untrusted input inside the WebAssembly module, you may need to consider your security model to include safekeeping the LLVM data stack as well. |
There was a problem hiding this comment.
Both WebAssembly VM and Wasm VM are used here. Maybe just use one of them for consistency?
|
|
||
| Since WebAssembly does not support virtual memory, the size of the LLVM data stack that is defined both for Wasm Workers but also the main thread will not be possible to grow at runtime. So if the Worker (or the main thread) runs out of stack space, the program behavior will be undefined. Use the Emscripten linker flag -sSTACK_OVERFLOW_CHECK=2 to emit runtime stack overflow checks into the program code to detect these situations during development. | ||
|
|
||
| Note that a stack overflow in this LLVM data stack does not imply stack overflow security vulnerabilities in the WebAssembly VM. The Wasm VM program flow stack is separate from this LLVM data stack, and guarded from access from Wasm code. However, if your threat model consists of executing untrusted program code, or executing a program from untrusted input inside the WebAssembly module, you may need to consider your security model to include safekeeping the LLVM data stack as well. |
There was a problem hiding this comment.
Non of this stuff is specific to wasm workers as far as I can tell, so I wonder if this should be documents in the theading docs and perhaps linked to from here?
|
|
||
| Both the Worker API and Wasm Workers API provide the user with ability to postMessage() function calls to the Worker. In Worker API, this message posting is restricted to need to originate/initiate from the main thread towards the Worker. With Wasm Workers however one can also postMessage() function calls to their parent (owning) thread. | ||
|
|
||
| If posting function calls with the Emscripten Worker API, it is required that the target Worker URL points to an Emscripten compiled program (so it has the ``Module`` structure to locate function names). Only functions that have been exported to the ``Module`` object are callable. With Wasm Workers, any C/C++ function may be posted, and does not need to be exported. |
There was a problem hiding this comment.
Could you format all these new paragaphs to 80 columns?
VirtualTim
reviewed
Apr 8, 2024
|
So the pre-allocated stack is for thread-local storage? @juj |
|
If the normal worker api can be spawned using a custom URL, how do we postmessage wasm function calls over? How does the worker api function? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update documentation on Wasm Workers stack size, and Wasm Workers vs Emscripten Workers API. Addresses #21610.