Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Alternative to ThreadLocalFunction

Aperta
#75 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

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

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

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di WebAssembly/shared-everything-threads

Tutte le issue di WebAssembly/shared-everything-threads

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.