N-API: Need SharedArrayBuffer api

[orange4glace]

needed feature :
napi_create_external_sharedarraybuffer
napi_get_sharedarraybuffer_info
napi_is_sharedarraybuffer

Since V8 api supports external sharedarraybuffer creation, it would be nice if n-api implements this.

[addaleax]

@orange4glace Is there a reason you closed this issue?

In any case, one issue with externalized SharedArrayBuffers is that you won’t actually be able to share them between Workers – that doesn’t make them all too useful.

[orange4glace]

@addleax Is there any reason that it can't be shared with workers? I am planning to use it with Electron so the native module will be loaded in Browser process.

PS. I closed it so I can make a PR instead.

[addaleax]

@orange4glace I don’t know how Electron/Chromium deals with that, I was just referring to the worker_threads module in Node.js 10+.

The reason it doesn’t work with our Workers is that SharedArrayBuffers can be garbage collected multiple times on different threads, and only when the last reference to it from any thread is gone, we can free it. For that, we need to know how to release the memory – that’s easiest if we don’t allow sharing externalized SharedArrayBuffers. You can still share internalized SharedArrayBuffers without any problems, whether they are created by addons or not.

[orange4glace]

Well, actually my module will fully manage the lifetime of the underlying buffer so I think I can manage that :?

[devsnek]

it's also not a feature that all js engines might support as it's not a spec operation, so putting it in napi doesn't make much sense.

[addaleax]

@orange4glace How does your module know when all references to it from all threads are gone?

[orange4glace]

@addaleax My plan is not accessing it after free it like manner of c pointer. Does it also matter?

[orange4glace]

@devsnek It's true but it is also true that SharedArrayBuffer is a part of ECMA 2017 standard.

[gabrielschulhof]

The commit message for #23279 should say that it fixes this issue, and this issue should be open.

[huningxin]

This is useful for an addon that needs to access Wasm shared memory.

For instance, the Web Neural Network (WebNN) node.js addon exchange tensor data with ML frameworks (e.g. TensorFlow.js Wasm backend and ONNXRuntime Wasm) through Wasm memory. This issue prevents WebNN node.js addon to work with multi-threaded build of these frameworks which use SharedArrayBuffer in Electron.js (webmachinelearning/webnn-native#106).

[dygabo]

This would be also useful for shared buffers that get updated with Atomic.exchange as Napi::ArrayBuffer seems to not be enough. At least wit node v14.18.0 Atomics.exchange returns: [object BigUint64Array] is not an integer shared typed array.
Atomics.exchange on a value in an ArrayBuffer seems to works fine with node v18.

Are there any plans of supporting SharedArrayBuffer in N-API?