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 https://github.com/nodejs/node/pull/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 (https://github.com/webmachinelearning/webnn-native/issues/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?

[yiv1]

Using SharedArrayBuffer to exchange data between modules written in node-addon-api and node.js will greatly simplify life. The current implementation of my module looks like a monster. I need this feature. Let's raise the priority for implementing SharedArrayBuffer.

Additionally, i want to manage signals using Atomics.notify and Atomics.wait. Is it possible?

[nomagick]

Alright then remove the plan for napi_create_external_sharedarraybuffer and push the rest of the APIs.

Previous PR: https://github.com/nodejs/node/pull/23279

Hi, @mhdawson could you please bring this to the NAPI team and let them take over?

[mhdawson]

@nomagick what we need is somebody to work on a new PR since the original one was closed. Is that something you would volunteer to do?

[nomagick]

what we need is somebody to work on a new PR since the original one was closed. Is that something you would volunteer to do?

@mhdawson Yes exactly. Thanks.

[github-actions[bot]]

There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the https://github.com/nodejs/node/labels/never-stale label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment. For more information on how the project manages feature requests, please consult the feature request management document.

[RobinWuu]

I'm curious about the current status of this feature. I'm also interested in how to ensure that the finalize callback is triggered only after all shared arraybuffers in all threads have been garbage-collected. Additionally, is it possible to support this feature in QuickJS and JavaScriptCore?

[mhdawson]

@RobinWuu I don't think there has been any progress.

[mertcanaltin]

Hello, I did a study for this place and have a one question in this pr : https://github.com/nodejs/node/pull/59071#issuecomment-3070124617

[mertcanaltin]

merged 🎉 , thanks all