@napi-rs/cli 3.10.5 → 3.10.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/docs/wasi.md CHANGED
@@ -667,3 +667,205 @@ Verified on the patched core: a contended probe under `wasmtime run -S
667
667
  threads` — `Mutex`, `Condvar`, `RwLock`, `park_until`, `notify_all`, `DashMap`
668
668
  — reports `ALL OK` with zero parking stubs left in the module, and rolldown's
669
669
  threaded WASI artifact passed its stability lane 3 of 3.
670
+
671
+ ## Shared memory growth on `wasm32-wasip1-threads`
672
+
673
+ Every thread of a threaded WASI addon runs on one shared `WebAssembly.Memory`.
674
+ V8 updates that memory's size only on the thread that grew it. Every other
675
+ thread keeps checking `memory.fill`, `memory.copy` and atomics against its old
676
+ size until it handles V8's grow interrupt, and on a host without V8's wasm trap
677
+ handler (`--disable-wasm-trap-handler`, or `--wasm-enforce-bounds-checks`) it
678
+ checks every load and store that way. Such a thread traps with `memory access
679
+ out of bounds` on heap pages another thread just grew. V8 fixed this in
680
+ [v8/v8@3424101](https://github.com/v8/v8/commit/34241014663390c72e08c123faef6fedf395be8e);
681
+ napi-rs works around it until the hosts it supports ship that fix.
682
+
683
+ The workaround is on for every addon built for exactly `wasm32-wasip1-threads`
684
+ with `napi` and `napi_build::setup()`. There is nothing to call or configure:
685
+
686
+ ```text
687
+ malloc / free / calloc / realloc / ... (Rust's System, wasi-libc, emnapi's `malloc` export)
688
+ -> napi's __wrap_* (napi-build links with --wrap)
689
+ LOCK (spin; sched_yield every 64 spins; never memory.atomic.wait)
690
+ another thread saw a larger memory? memory.grow(0) refresh this thread
691
+ dlmalloc
692
+ -> __wrap_sbrk: the reserve first, else grow >= 16 MiB,
693
+ refresh and publish the new size
694
+ UNLOCK
695
+
696
+ task poll, block_on poll, blocking closure (napi-async-runtime)
697
+ AsyncTask compute, AsyncRuntimeTask poll, (napi)
698
+ napi's default Tokio runtime and spawn_blocking
699
+ -> another thread saw a larger memory? memory.grow(0) one atomic load + one thread-local load
700
+ ```
701
+
702
+ - **The allocator lock.** `napi_build::setup()` links with `--wrap` for the 10
703
+ entries of wasi-libc's dlmalloc and for `sbrk`, so every allocation reaches a
704
+ `__wrap_*` function in `napi`. It takes one lock, refreshes the thread's size
705
+ when another thread has seen a larger memory, and runs the real call. The
706
+ thread that grows the memory publishes the new size before it unlocks, so
707
+ every thread is current before dlmalloc touches a byte for it. The lock also
708
+ covers calloc's zero fill and realloc's copy, and C code that calls `sbrk`
709
+ itself takes it too. It spins like dlmalloc's own lock, so it is safe on a
710
+ browser main thread, where `memory.atomic.wait` traps.
711
+ - **The handoff refresh.** Memory can reach a thread without an allocation
712
+ there: a task that allocated on one thread resumes on another, or a closure
713
+ runs on a pool thread. `napi-async-runtime` and napi's own cross-thread
714
+ entries check the size before they run such work.
715
+ - **The heap break.** dlmalloc first uses the pages between the module's own
716
+ memory and the memory the loader created (`napi.wasm.initialMemory`): they
717
+ exist on every thread from the start, so they never need a refresh, and
718
+ nothing grows until they are used. Past them it only uses pages it grew
719
+ itself, at least 16 MiB at a time, so pages another allocator grew never
720
+ reach dlmalloc. The heap never reaches 2 GiB: an allocation that would pass
721
+ it fails. Node's `node:wasi` (v24 and later) answers `EINVAL` to
722
+ `clock_time_get` and `fd_seek` when a pointer is at or above 2 GiB.
723
+
724
+ The threaded `.wasm` exports `malloc` and `free` as before (`@emnapi/core`
725
+ calls them); they now go through the lock. It also exports the 11 `__wrap_*`
726
+ functions, `napi_wasm_heap_sync_stat`, `napi_wasm_thread_crashed` and
727
+ `napi_wasm_thread_crash_flag_address`, because Rust exports every
728
+ `#[no_mangle]` function of a cdylib. They are not an API.
729
+ The threadless `wasm32-wasip1` artifact has none of this.
730
+
731
+ The addon's `napi-build` must be the same package as `napi`'s own
732
+ build-dependency (a path or git `napi` needs `napi-build` from the same
733
+ checkout). With two copies, the addon's `setup()` does not wrap the allocator,
734
+ and the link fails with an undefined symbol,
735
+ `napi_wasi_heap_sync_needs_napi_build_setup_with_wasi_heap_sync`.
736
+
737
+ ### Test counters
738
+
739
+ `napi_wasm_heap_sync_stat(index)` returns one counter as a `u32`. It is for
740
+ tests and diagnosis; `examples/wasi-heap-sync/stress.mjs` and rolldown's
741
+ threaded stress test read it by index, so an index keeps its meaning.
742
+
743
+ | index | value |
744
+ | --------- | ------------------------------------------------------------------------------------------- |
745
+ | 0 | heap growths: `memory.grow(n > 0)` calls by `__wrap_sbrk` |
746
+ | 1 | refreshes after taking the lock (including each thread's first) |
747
+ | 2 | blocks that ended past the thread's refreshed size when dlmalloc returned them; must stay 0 |
748
+ | 3 | the heap break, in pages (rounded up); 0 before the first `sbrk` |
749
+ | 4 | `__heap_end` (where the break starts), in pages; 0 before the first `sbrk` |
750
+ | 5 | refreshes at handoffs (napi-async-runtime and napi's cross-thread entries) |
751
+ | any other | `u32::MAX` |
752
+
753
+ With the loader's default memory a small load reads 0 at index 0: the heap fits
754
+ in the reserve and never grows.
755
+
756
+ ### Cost
757
+
758
+ Measured in rolldown on its copy of this code, before napi-rs took it over:
759
+ the same lock and break. napi's copy adds the check that keeps other
760
+ allocators' pages out of the break, and keeps the shared size in a cache line
761
+ of its own. Release wasm, Node 24.21 on arm64, 10 interleaved rounds, medians
762
+ in ms:
763
+
764
+ | load | before the lock | with the lock | cost |
765
+ | --------------------------------- | --------------- | ------------- | ---- |
766
+ | MultiThread, 16 builds | 310.5 | 334.5 | 8% |
767
+ | MultiThread, 16 builds, JS plugin | 1518 | 1589.5 | 5% |
768
+ | MultiThread, parse 16x3 | 218.5 | 241 | 10% |
769
+ | CurrentThread, parse 16x3 | 216.5 | 240.5 | 11% |
770
+ | CurrentThread, transform 16x3 | 623.5 | 640 | 3% |
771
+
772
+ "Before the lock" already grew the heap at least 16 MiB at a time. That part
773
+ of the workaround had made the same loads 1.6-3.2x faster than growing in
774
+ dlmalloc's own small steps (transform: no change), and the lock keeps most of
775
+ that gain. The handoff check alone measured at noise level. Other workloads,
776
+ x64, Linux, Windows and browsers are not measured.
777
+
778
+ ### Opting out
779
+
780
+ Pass `--cfg napi_wasi_no_heap_sync` in the target rustflags, for example
781
+ `RUSTFLAGS="--cfg napi_wasi_no_heap_sync" napi build --target
782
+ wasm32-wasip1-threads`. `napi` then leaves out the wrappers and its handoff
783
+ checks, and `napi-build` leaves out the `--wrap` link arguments; both read the
784
+ same cfg, so they cannot come apart. `napi-async-runtime`'s check stays, but it
785
+ never fires: nothing publishes a larger size. `napi_build::setup()` declares
786
+ the cfg, so addon code can test `#[cfg(napi_wasi_no_heap_sync)]` too. Without
787
+ the workaround the trap above comes back on hosts without the V8 fix.
788
+
789
+ ### What it does not cover
790
+
791
+ - A `#[global_allocator]` that calls `memory.grow` itself (mimalloc's WASI
792
+ build, talc, lol_alloc, the `dlmalloc` crate) is not locked, and its growth
793
+ is never published. One that ends in libc `malloc`, like std's `System`, is
794
+ locked.
795
+ - Memory that reaches a running thread mid-poll (a channel message, an `Arc`)
796
+ and is touched there before that thread's next allocation or handoff, after
797
+ another thread grew the memory. Below the reserve nothing grows. A
798
+ threadsafe-function call, deferred or async work delivered on the JavaScript
799
+ thread is covered: between taking it off its queue and calling back into the
800
+ module, emnapi runs JavaScript frames (`napi_open_handle_scope`,
801
+ `napi_get_reference_value`, `emnapi_is_node_binding_available`,
802
+ `_emnapi_callback_into_module`), and a JavaScript frame handles V8's grow
803
+ interrupt. What remains there is emnapi's own read of the queue node in C, on
804
+ hosts without the trap handler.
805
+ - Work on threads the addon starts or runs itself: a runtime passed to
806
+ `create_custom_tokio_runtime`, direct `tokio::task::spawn_blocking` calls,
807
+ and a host's own threads outside `napi-async-runtime`'s scheduler.
808
+ - A thread that crashes while it holds the lock leaves the others spinning, as
809
+ a crash inside dlmalloc's own lock always did.
810
+
811
+ ## Shutdown polls never wait
812
+
813
+ A loader's `dispose()` runs the environment cleanup in two phases with a poll
814
+ between them: `napi_prepare_wasm_env_cleanup_begin`, then
815
+ `napi_wasm_runtime_work_pending` once per event-loop turn until it answers 0,
816
+ then `napi_prepare_wasm_env_cleanup_finish`. The poll never blocks, and that
817
+ includes locks: when a lock the answer is read under is held by another
818
+ thread, it answers 1 and the loader polls again on its next turn. On
819
+ `wasm32-wasip1-threads` a thread that traps unwinds nothing, so a lock it held
820
+ stays held; a poll that waited for it would park the JavaScript thread in
821
+ `memory.atomic.wait32` for good, before the loader can see the crash. A custom
822
+ `AsyncRuntime` backend must keep the same rule in `shutdown_work_pending`. The
823
+ process-exit teardown has no turns to give and makes the single blocking call,
824
+ `napi_prepare_wasm_env_cleanup`.
825
+
826
+ The two phases themselves may wait. With `napi-async-runtime` on
827
+ `wasm32-wasip1-threads` they wait in 1 ms slices on the JavaScript thread, and
828
+ between slices read the addon's crash flag: one 4-byte word in the shared wasm
829
+ memory. Once it is set, the next slice traps, and the loader reports the crash
830
+ instead of hanging.
831
+
832
+ The generated worker sets that word itself, with `Atomics.store`, so it needs
833
+ no wasm instance:
834
+
835
+ ```
836
+ loader thread pool worker
837
+ ───────────── ───────────
838
+ instantiate; in beforeInit:
839
+ napi_wasm_thread_crash_flag_address()
840
+ view = Int32Array(memory, address, 1)
841
+ spawn → Worker({ workerData: { load → start → run
842
+ crashFlag, crashReport, ...
843
+ addonCrashFlag: view } }) dies (trap, error, failed load):
844
+ ... write crashReport
845
+ cleanup waits in slices ◄────────────── Atomics.store(crashFlag, 1)
846
+ view word is 1 → trap Atomics.store(addonCrashFlag, 1)
847
+ catch → crash rejection emnapi's own error report
848
+ ```
849
+
850
+ - The Node worker gets the view in `workerData`. The browser worker gets it by
851
+ `postMessage`: the browser pool is created before the wasm is instantiated,
852
+ so the loader posts it to each pool worker after `beforeInit`, and to a
853
+ worker created later right away.
854
+ - The loader's crash flag always goes up first, so when the trap reaches the
855
+ loader it already sees the crash.
856
+ - A worker whose own setup throws (`@napi-rs/wasm-runtime` cannot be
857
+ resolved, say) raises both flags too, then fails as before.
858
+ - A worker that fails while it loads — after the thread spawn that created it
859
+ already returned — raises the flag the same way. `napi_wasm_thread_crashed`,
860
+ which stores into the same word, is only the fallback for a worker that has
861
+ an instance but no view.
862
+ - An addon built with an older napi has no address export: the loader passes
863
+ no view, and the waits stay unbounded, as before.
864
+
865
+ What still cannot raise the flag: a worker that fails before any of its own
866
+ code runs, or that is killed from outside — the `Worker` cannot start, runs
867
+ out of memory, or is terminated by its resource limits. The loader sees those
868
+ only through the worker's `'error'` or `'exit'` event, which needs a turn of
869
+ its event loop, so a cleanup wait already in progress keeps waiting. The same
870
+ holds before `beforeInit`: a thread spawned while the wasm initializes gets a
871
+ worker with no view.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@napi-rs/cli",
3
- "version": "3.10.5",
3
+ "version": "3.10.6",
4
4
  "description": "Cli tools for napi-rs",
5
5
  "author": "LongYinan <lynweklm@gmail.com>",
6
6
  "homepage": "https://napi.rs/",
@@ -87,7 +87,7 @@
87
87
  "emnapi": "^2.0.0-alpha.4",
88
88
  "empathic": "^2.0.1",
89
89
  "env-paths": "^4.0.0",
90
- "oxc-parser": "^0.151.0",
90
+ "oxc-parser": "^0.152.0",
91
91
  "tsdown": "^0.23.0",
92
92
  "tslib": "^2.8.1"
93
93
  },
@@ -1351,6 +1351,36 @@ Generated by [AVA](https://avajs.dev).
1351
1351
  return __rollbackWasmEnvForWasiInitialization()␊
1352
1352
  }␊
1353
1353
  ␊
1354
+ // A view of the addon's crash flag, one word of the shared wasm memory, for the␊
1355
+ // pool workers: they raise it when their wasm thread dies, and the shutdown␊
1356
+ // waits inside the cleanup calls on this thread then trap instead of waiting on␊
1357
+ // the dead thread for good. Undefined for an addon built with an older napi.␊
1358
+ let __wasiAddonCrashFlag␊
1359
+ ␊
1360
+ function __captureWasiAddonCrashFlag(instance) {␊
1361
+ try {␊
1362
+ const getAddress = instance.exports.napi_wasm_thread_crash_flag_address␊
1363
+ if (typeof getAddress !== 'function') {␊
1364
+ return␊
1365
+ }␊
1366
+ const address = getAddress() >>> 0␊
1367
+ const buffer = __sharedMemory.buffer␊
1368
+ if (address === 0 || address % 4 !== 0 || address + 4 > buffer.byteLength) {␊
1369
+ return␊
1370
+ }␊
1371
+ __wasiAddonCrashFlag = new Int32Array(buffer, address, 1)␊
1372
+ } catch {}␊
1373
+ }␊
1374
+ ␊
1375
+ function __shareWasiAddonCrashFlag(worker) {␊
1376
+ if (__wasiAddonCrashFlag === undefined) {␊
1377
+ return␊
1378
+ }␊
1379
+ try {␊
1380
+ worker.postMessage({ __napiRsAddonCrashFlag: __wasiAddonCrashFlag })␊
1381
+ } catch {}␊
1382
+ }␊
1383
+ ␊
1354
1384
  let __wasiModule␊
1355
1385
  let __napiModule␊
1356
1386
  ␊
@@ -1381,6 +1411,7 @@ Generated by [AVA](https://avajs.dev).
1381
1411
  type: 'module',␊
1382
1412
  })␊
1383
1413
  __wasiWorkers.add(worker)␊
1414
+ __shareWasiAddonCrashFlag(worker)␊
1384
1415
  ␊
1385
1416
  ␊
1386
1417
  return worker␊
@@ -1396,6 +1427,10 @@ Generated by [AVA](https://avajs.dev).
1396
1427
  },␊
1397
1428
  beforeInit({ instance }) {␊
1398
1429
  __napiInstance = instance␊
1430
+ __captureWasiAddonCrashFlag(instance)␊
1431
+ for (const worker of __wasiWorkers) {␊
1432
+ __shareWasiAddonCrashFlag(worker)␊
1433
+ }␊
1399
1434
  for (const name of Object.keys(instance.exports)) {␊
1400
1435
  if (name.startsWith('__napi_register__')) {␊
1401
1436
  instance.exports[name]()␊
@@ -2763,6 +2798,36 @@ Generated by [AVA](https://avajs.dev).
2763
2798
  return __rollbackWasmEnvForWasiInitialization()␊
2764
2799
  }␊
2765
2800
  ␊
2801
+ // A view of the addon's crash flag, one word of the shared wasm memory, for the␊
2802
+ // pool workers: they raise it when their wasm thread dies, and the shutdown␊
2803
+ // waits inside the cleanup calls on this thread then trap instead of waiting on␊
2804
+ // the dead thread for good. Undefined for an addon built with an older napi.␊
2805
+ let __wasiAddonCrashFlag␊
2806
+ ␊
2807
+ function __captureWasiAddonCrashFlag(instance) {␊
2808
+ try {␊
2809
+ const getAddress = instance.exports.napi_wasm_thread_crash_flag_address␊
2810
+ if (typeof getAddress !== 'function') {␊
2811
+ return␊
2812
+ }␊
2813
+ const address = getAddress() >>> 0␊
2814
+ const buffer = __sharedMemory.buffer␊
2815
+ if (address === 0 || address % 4 !== 0 || address + 4 > buffer.byteLength) {␊
2816
+ return␊
2817
+ }␊
2818
+ __wasiAddonCrashFlag = new Int32Array(buffer, address, 1)␊
2819
+ } catch {}␊
2820
+ }␊
2821
+ ␊
2822
+ function __shareWasiAddonCrashFlag(worker) {␊
2823
+ if (__wasiAddonCrashFlag === undefined) {␊
2824
+ return␊
2825
+ }␊
2826
+ try {␊
2827
+ worker.postMessage({ __napiRsAddonCrashFlag: __wasiAddonCrashFlag })␊
2828
+ } catch {}␊
2829
+ }␊
2830
+ ␊
2766
2831
  let __wasiModule␊
2767
2832
  let __napiModule␊
2768
2833
  ␊
@@ -2793,6 +2858,7 @@ Generated by [AVA](https://avajs.dev).
2793
2858
  type: 'module',␊
2794
2859
  })␊
2795
2860
  __wasiWorkers.add(worker)␊
2861
+ __shareWasiAddonCrashFlag(worker)␊
2796
2862
  ␊
2797
2863
  worker.addEventListener('message', (event) => {␊
2798
2864
  if (event.data && typeof event.data === 'object' && event.data.type === 'error') {␊
@@ -2821,6 +2887,10 @@ Generated by [AVA](https://avajs.dev).
2821
2887
  },␊
2822
2888
  beforeInit({ instance }) {␊
2823
2889
  __napiInstance = instance␊
2890
+ __captureWasiAddonCrashFlag(instance)␊
2891
+ for (const worker of __wasiWorkers) {␊
2892
+ __shareWasiAddonCrashFlag(worker)␊
2893
+ }␊
2824
2894
  for (const name of Object.keys(instance.exports)) {␊
2825
2895
  if (name.startsWith('__napi_register__')) {␊
2826
2896
  instance.exports[name]()␊
@@ -4194,6 +4264,36 @@ Generated by [AVA](https://avajs.dev).
4194
4264
  return __rollbackWasmEnvForWasiInitialization()␊
4195
4265
  }␊
4196
4266
  ␊
4267
+ // A view of the addon's crash flag, one word of the shared wasm memory, for the␊
4268
+ // pool workers: they raise it when their wasm thread dies, and the shutdown␊
4269
+ // waits inside the cleanup calls on this thread then trap instead of waiting on␊
4270
+ // the dead thread for good. Undefined for an addon built with an older napi.␊
4271
+ let __wasiAddonCrashFlag␊
4272
+ ␊
4273
+ function __captureWasiAddonCrashFlag(instance) {␊
4274
+ try {␊
4275
+ const getAddress = instance.exports.napi_wasm_thread_crash_flag_address␊
4276
+ if (typeof getAddress !== 'function') {␊
4277
+ return␊
4278
+ }␊
4279
+ const address = getAddress() >>> 0␊
4280
+ const buffer = __sharedMemory.buffer␊
4281
+ if (address === 0 || address % 4 !== 0 || address + 4 > buffer.byteLength) {␊
4282
+ return␊
4283
+ }␊
4284
+ __wasiAddonCrashFlag = new Int32Array(buffer, address, 1)␊
4285
+ } catch {}␊
4286
+ }␊
4287
+ ␊
4288
+ function __shareWasiAddonCrashFlag(worker) {␊
4289
+ if (__wasiAddonCrashFlag === undefined) {␊
4290
+ return␊
4291
+ }␊
4292
+ try {␊
4293
+ worker.postMessage({ __napiRsAddonCrashFlag: __wasiAddonCrashFlag })␊
4294
+ } catch {}␊
4295
+ }␊
4296
+ ␊
4197
4297
  let __wasiModule␊
4198
4298
  let __napiModule␊
4199
4299
  ␊
@@ -4224,6 +4324,7 @@ Generated by [AVA](https://avajs.dev).
4224
4324
  type: 'module',␊
4225
4325
  })␊
4226
4326
  __wasiWorkers.add(worker)␊
4327
+ __shareWasiAddonCrashFlag(worker)␊
4227
4328
  worker.addEventListener('message', __wasmCreateOnMessageForFsProxy(__fs))␊
4228
4329
  ␊
4229
4330
  worker.addEventListener('message', (event) => {␊
@@ -4253,6 +4354,10 @@ Generated by [AVA](https://avajs.dev).
4253
4354
  },␊
4254
4355
  beforeInit({ instance }) {␊
4255
4356
  __napiInstance = instance␊
4357
+ __captureWasiAddonCrashFlag(instance)␊
4358
+ for (const worker of __wasiWorkers) {␊
4359
+ __shareWasiAddonCrashFlag(worker)␊
4360
+ }␊
4256
4361
  for (const name of Object.keys(instance.exports)) {␊
4257
4362
  if (name.startsWith('__napi_register__')) {␊
4258
4363
  instance.exports[name]()␊
@@ -9631,7 +9736,31 @@ Generated by [AVA](https://avajs.dev).
9631
9736
  },␊
9632
9737
  })␊
9633
9738
  ␊
9739
+ // When this wasm thread dies, raise the addon's crash flag before emnapi reports␊
9740
+ // it. The loader thread may be inside wasm, in a cleanup call that waits on this␊
9741
+ // thread; the flag is what those waits check between short slices, and once it␊
9742
+ // is up they trap instead of waiting for good. It is a word in the shared wasm␊
9743
+ // memory, and the loader posts a view of it (see␊
9744
+ // napi_wasm_thread_crash_flag_address) after it instantiated the wasm, or right␊
9745
+ // after it created this worker. No view, no flag: an addon built with an older␊
9746
+ // napi, or a failure before the view arrived.␊
9747
+ let __addonCrashFlag␊
9748
+ const __beforeReportError = handler.beforeReportError␊
9749
+ handler.beforeReportError = function (...args) {␊
9750
+ if (__addonCrashFlag !== undefined) {␊
9751
+ try {␊
9752
+ Atomics.store(__addonCrashFlag, 0, 1)␊
9753
+ } catch {}␊
9754
+ }␊
9755
+ return __beforeReportError.apply(this, args)␊
9756
+ }␊
9757
+ ␊
9634
9758
  globalThis.onmessage = function (e) {␊
9759
+ const data = e && e.data␊
9760
+ if (data && data.__napiRsAddonCrashFlag instanceof Int32Array) {␊
9761
+ __addonCrashFlag = data.__napiRsAddonCrashFlag␊
9762
+ return␊
9763
+ }␊
9635
9764
  handler.handle(e)␊
9636
9765
  }␊
9637
9766
  `
@@ -9687,7 +9816,31 @@ Generated by [AVA](https://avajs.dev).
9687
9816
  }␊
9688
9817
  })␊
9689
9818
  ␊
9819
+ // When this wasm thread dies, raise the addon's crash flag before emnapi reports␊
9820
+ // it. The loader thread may be inside wasm, in a cleanup call that waits on this␊
9821
+ // thread; the flag is what those waits check between short slices, and once it␊
9822
+ // is up they trap instead of waiting for good. It is a word in the shared wasm␊
9823
+ // memory, and the loader posts a view of it (see␊
9824
+ // napi_wasm_thread_crash_flag_address) after it instantiated the wasm, or right␊
9825
+ // after it created this worker. No view, no flag: an addon built with an older␊
9826
+ // napi, or a failure before the view arrived.␊
9827
+ let __addonCrashFlag␊
9828
+ const __beforeReportError = handler.beforeReportError␊
9829
+ handler.beforeReportError = function (...args) {␊
9830
+ if (__addonCrashFlag !== undefined) {␊
9831
+ try {␊
9832
+ Atomics.store(__addonCrashFlag, 0, 1)␊
9833
+ } catch {}␊
9834
+ }␊
9835
+ return __beforeReportError.apply(this, args)␊
9836
+ }␊
9837
+ ␊
9690
9838
  globalThis.onmessage = function (e) {␊
9839
+ const data = e && e.data␊
9840
+ if (data && data.__napiRsAddonCrashFlag instanceof Int32Array) {␊
9841
+ __addonCrashFlag = data.__napiRsAddonCrashFlag␊
9842
+ return␊
9843
+ }␊
9691
9844
  handler.handle(e)␊
9692
9845
  }␊
9693
9846
  `
@@ -9751,7 +9904,31 @@ Generated by [AVA](https://avajs.dev).
9751
9904
  }␊
9752
9905
  })␊
9753
9906
  ␊
9907
+ // When this wasm thread dies, raise the addon's crash flag before emnapi reports␊
9908
+ // it. The loader thread may be inside wasm, in a cleanup call that waits on this␊
9909
+ // thread; the flag is what those waits check between short slices, and once it␊
9910
+ // is up they trap instead of waiting for good. It is a word in the shared wasm␊
9911
+ // memory, and the loader posts a view of it (see␊
9912
+ // napi_wasm_thread_crash_flag_address) after it instantiated the wasm, or right␊
9913
+ // after it created this worker. No view, no flag: an addon built with an older␊
9914
+ // napi, or a failure before the view arrived.␊
9915
+ let __addonCrashFlag␊
9916
+ const __beforeReportError = handler.beforeReportError␊
9917
+ handler.beforeReportError = function (...args) {␊
9918
+ if (__addonCrashFlag !== undefined) {␊
9919
+ try {␊
9920
+ Atomics.store(__addonCrashFlag, 0, 1)␊
9921
+ } catch {}␊
9922
+ }␊
9923
+ return __beforeReportError.apply(this, args)␊
9924
+ }␊
9925
+ ␊
9754
9926
  globalThis.onmessage = function (e) {␊
9927
+ const data = e && e.data␊
9928
+ if (data && data.__napiRsAddonCrashFlag instanceof Int32Array) {␊
9929
+ __addonCrashFlag = data.__napiRsAddonCrashFlag␊
9930
+ return␊
9931
+ }␊
9755
9932
  handler.handle(e)␊
9756
9933
  }␊
9757
9934
  `