Alternative to ThreadLocalFunction
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- javascript, wasm
- Ambito
- api, backend-api-design
Direzione di ricerca
Inizia leggendo il concetto esistente di ThreadLocalFunction e gli entry point DispatchFunction, DispatchTable e bindToDispatch proposti nell’issue. Chiarisci il comportamento della JS-API per le tabelle attive, il rooting, il trapping e l’ambito del thread o del realm. Per considerarlo completato sarebbe necessario un design condiviso, non solo lo schema attuale e le alternative.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Apologies for adding yet another idea to consider, but wanted to have it written up somewhere. This came from some discussions with Luke (cc @lukewagner) on how shared wasm functions could call unshared functions without strong shared to unshared GC edges.
The idea is to avoid having the 'unshared function wrapper' that shared wasm calls from being the thing that roots the unshared function, but instead have it be rooted by having the unshared entry point into shared wasm root it.
Here's a sketch:
// ### Instantiation thread ###
// Create a 'dispatch function' which is a shared wasm function that when called invokes
// a corresponding unshared function bound in the active dispatch table.
let dispatchConsoleLog = new DispatchFunction({params: [] results: []});
assert(dispatchConsoleLog instanceof WebAssembly.Function === true);
assert(dispatchConsoleLog.type().shared === true);
// Instantiate a module that imports the dispatch function
let mod = wasmTextToBinary(`(module
(func shared (import "dispatchFuncs" "dispatchConsoleLog") $dispatchConsoleLog)
(func shared (export "sharedRun") call $dispatchConsoleLog)
)`);
let instance = new WebAssembly.Instance(mod, {"dispatchFuncs": {dispatchConsoleLog}});
postMessage(instance.exports.sharedRun);
// ### Execution thread ###
// sharedRun() would trap during call to imported dispatch function
// as there is no dispatch table active.
assertTrap(() => sharedRun());
// A dispatch table is specific to a thread (or maybe realm)
let dispatch = new DispatchTable();
// Create a permanent mapping from dispatch function to unshared function
dispatch.bind(dispatchConsoleLog, console.log);
// Need to bind shared functions to a specific dispatch table, resulting
// in an unshared function.
let unsharedRun = sharedRun.bindToDispatch(dispatch);
unsharedRun();
assert(unsharedRun instanceof WebAssembly.Function === true);
assert(unsharedRun.type().shared === false);
DispatchTable acts as a map from shared DispatchFunction pointer to unshared function. Entries can only be added, not removed. To free a mapping, you'd let the whole DispatchTable become collected.
A shared DispatchFunction doesn't keep alive any unshared functions, it basically is just a key to a DispatchTable. The unshared DispatchTable is what keeps the unshared functions alive on each thread. This avoids the need for web engines to do global marking of cross-thread JS and C++ heaps.
We'd modify the JS-API to track an 'active' dispatch table that can be set by through entering a 'bindToDispatch()' function. When a DispatchFunction is called, it does a lookup in the active table for what it has been bound to, then invokes that.
The API is similar to ThreadLocalFunction (which also has the notion of each thread binding the unshared wrapper to that thread's unshared function). The one difference is that every thread must activate a dispatch table before entering the shared code. I think with bindToDispatch (and other similar possibilities), this could be ergonomic.
One useful thing here for the case of emscripten with dlopen and multithreading is that all the modules could use the same dispatch table, so you wouldn't need to switch between tables on every cross-module indirect call. The keys to the table are pointers, so there's no chance of accidental collisions, and new entries can be added over an execution.
There are some details that could be tweaked while maintaining the core idea. Instead of using a 'DispatchFunction' as a key, we could create a "wasm:dispatch-function" import namespace where the string fields in that act as the key to the dispatch table. We could also investigate other ways of maintaining the active dispatch table instead of a 'bindToDispatch'.
- Lingua principale
- WebAssembly
- Stelle
- 97
- Fork
- 6
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di WebAssembly/shared-everything-threads
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
WebAssembly/shared-everything-threads#119 · 2 commenti ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
WebAssembly/shared-everything-threads#114 · 7 commenti ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
WebAssembly/shared-everything-threads#105 · 6 commenti ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
WebAssembly/shared-everything-threads#99 · 5 commenti ·
Tutte le issue di WebAssembly/shared-everything-threads
Issue simili
-
Bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
Automattic/safe-publish#593 ·
-
executions.Query — startDate and timeRange filters are sent with inverted comparison operators Apertaarea/plugin
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
kestra-io/plugin-kestra#190 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
xinnan-tech/xiaozhi-fde-talk#263 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
pending-maintainer-response pending-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100