Repository navigation
N-API: Need SharedArrayBuffer api #23276
Description
Activity
- changed the title
[-]N-API: Need SharedArrayBuffer feature[/-][+]N-API: Need SharedArrayBuffer api[/+]on Oct 5, 2018 @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.Reacted by orange4glace and Andrej KirejeŭReacted by 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.
Reacted by Andrej Kirejeŭ@orange4glace I don’t know how Electron/Chromium deals with that, I was just referring to the
worker_threadsmodule 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.
Reacted by orange4glaceWell, actually my module will fully manage the lifetime of the underlying buffer so I think I can manage that :?
Reacted by Andrej Kirejeŭ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.
@orange4glace How does your module know when all references to it from all threads are gone?
@addaleax My plan is not accessing it after free it like manner of c pointer. Does it also matter?
@devsnek It's true but it is also true that SharedArrayBuffer is a part of ECMA 2017 standard.
The commit message for #23279 should say that it fixes this issue, and this issue should be open.
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).
Reacted by Yanlong WangThis 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?
5 remaining items
There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale
Issues and PRs exempt from automated stale handling. 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.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?Hello, I did a study for this place and have a one question in this pr : #59071 (comment)
merged 🎉 , thanks all
Reacted by Chengzhong Wu
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.