RFC: WebWorker interface via an N-API module
I maintainer di solito rispondono entro 1 giorno
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à
- Tranquilla
- Stack tecnologico
- cpp, javascript
- Ambito
- backend-api-design, devtools
Direzione di ricerca
Inizia leggendo le issue correlate #116, #183 e #185, insieme al lavoro del fork v7 a cui si fa riferimento, per comprendere le assunzioni su N-API e runtime. Valuta quindi la superficie Worker proposta, il modello di threading per engine, i requisiti di structured clone e transferable e le questioni relative al ciclo di vita. Il lavoro è completo quando le questioni di progettazione aperte sono state risolte in un piano di implementazione condiviso.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Intent
Land the N‑API + underlying JS‑runtime updates needed to expose a WebWorker interface as an N‑API module, so the Factotum BabylonJS app can lift‑and‑shift from the browser/PWA into BabylonNative with minimal code change.
Why this matters
- Factotum's data pipeline was moved onto a Web Worker; on‑device that gave a ~10 fps uplift on Quest 1/2, Pico 4, and similar standalone headsets (pulling the pipeline off the render thread).
- To carry that architecture into BabylonNative, BabylonNative needs a Worker‑compatible surface — cleanest delivered as an N‑API module exposing the
Workerinterface (construct,postMessage, transferables,onmessage/onerror,terminate), backed by the runtime's threading/isolate model. - Revenue imperative: in‑app purchases are broken/non‑existent for immersive PWAs on the Meta Horizon Store and Pico Store (even as of June 2026). Shipping as a native (BabylonNative) app is currently the only viable monetization path on those stores, so unblocking Factotum → BabylonNative is business‑critical for BabylonJS‑community devs whose complex BabylonJS apps depend on revenue (and storefront placement).
Why the N‑API track comes first
A Worker‑as‑N‑API‑module needs a solid, modern N‑API surface across the runtimes BabylonNative ships:
- N‑API conformance + cross‑engine parity (the #116 + v7 track) so addons behave the same on V8 / JSC / Chakra.
- A shared
libnapiso in‑process addons resolve modules dynamically, allowing for less hacky build setups to exclude N-API plug-ins that aren't used and align to other runtimes (#183). - On Android specifically, a JSC that can keep up (see the jsc‑android → Bun‑JSC RFC, #186) — Worker payloads use modern JS (structured clone, BigInt, transferables) that 2019 JSC can't even parse.
Proposed shape (for discussion)
- An N‑API module exposing a
Workerclass: construct from a script/module;postMessagewith structured‑clone + transferableArrayBuffers;terminate;onmessage/onerror. - Backed by a second runtime instance/isolate on a worker thread, with a thread‑safe channel (
napi_threadsafe_functionor equivalent). - Reuse BabylonNative's existing JS dispatch / task‑runner where possible.
Open questions
- Per‑engine threading model (V8 isolate‑per‑worker; JSC
JSContextGroup; Chakra runtime‑per‑worker) and whichnapi_*primitives we standardize on. - Structured‑clone + transferable depth (ties into the v7
ArrayBufferdetach work). - Lifecycle/GC ownership across the thread boundary.
Related N‑API track: #116, #183, #185 (+ the v7 work staged as fork PR rebeckerspecialties/JsRuntimeHost#4).
- Lingua principale
- C++
- Stelle
- 22
- Fork
- 23
- Merge medio
- 4g 8h
- PR unite (30g)
- 3
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi 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 BabylonJS/JsRuntimeHost
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
BabylonJS/JsRuntimeHost#234 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
BabylonJS/JsRuntimeHost#173 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
BabylonJS/JsRuntimeHost#241 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
BabylonJS/JsRuntimeHost#228 ·
I maintainer di solito rispondono entro 1 giorno
-
napi_unwrap does not reject objects that were never wrapped (V8 port faults, QuickJS port confuses types)Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 68/100
BabylonJS/JsRuntimeHost#226 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di BabylonJS/JsRuntimeHost
Issue simili
-
UPC C++ link do not workAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
CI tracking issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
espressif/esp-matter#1874 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
KavrakiLab/vamp#126 ·
-
cudev: Fix MSVC build failures with 64-bit integers (int64_t/uint64_t) in vec_traits.hppForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
opencv/opencv_contrib#4231 ·
I maintainer di solito rispondono entro 1 giorno