You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Memory<T> to TypedArray<T> on Electron 19.1.9 Worked fine. But did not worked on higher Electron #383
I Test Memory<T> to TypedArray<T> on Electron 19.1.9,That Worked fine and has amazing Performance.
But when I Test on higher Electron, such as 32.1.2, it was not worked. And reported an error:
External buffers are not allowed: Error in CreateExternalArrayBuffer at D:\a\1\s\src\NodeApi\JSValue.cs:264
I did some research,the use of External buffers has actually been officially banned. electron/electron#35801
Does anyone know how to turn on External buffers support in the new version of Electron? Like turn it on by some command parameter or something。
Or has any Other way to transfer big data(such as 100MB) from dotnet to nodejs?
electron/electron#35801 appears to be quite a controversial issue, but the Electron team seems to believe the limitation is necessary for security.
As a workaround, node-api-dotnet probably will need to handle the new napi_no_external_buffers_allowed status code and fall back to copying the memory instead of using external buffers. That's very unfortunate since it can have a major performance impact in some scenarios, and doesn't have the same semantics as shared memory.
I was aware about the change, but forgot to bring it to our discussion since we did not discuss the Electron integration.
Recently one developer shared with Node-API team a technique where he creates a big ArrayBuffer, and then uses slices of that buffer for several TypedArrays. I wonder if we can use the same technique to improve speed.
Activity
jasongin commentedon Sep 30, 2024
electron/electron#35801 appears to be quite a controversial issue, but the Electron team seems to believe the limitation is necessary for security.
As a workaround, node-api-dotnet probably will need to handle the new
napi_no_external_buffers_allowedstatus code and fall back to copying the memory instead of using external buffers. That's very unfortunate since it can have a major performance impact in some scenarios, and doesn't have the same semantics as shared memory.vmoroz commentedon Sep 30, 2024
I was aware about the change, but forgot to bring it to our discussion since we did not discuss the Electron integration.
Recently one developer shared with Node-API team a technique where he creates a big ArrayBuffer, and then uses slices of that buffer for several TypedArrays. I wonder if we can use the same technique to improve speed.
Hiwen commentedon Oct 1, 2024
Thanks for reply Jason Ginchereau (@jasongin). I think it's better to close this issue, and discuss this topic on issue384.
jasongin commentedon Oct 3, 2024
I closed #384 as a duplicate of this one. I didn't notice when opened that issue that you had already created this one.
fstanis commentedon Mar 4, 2025
Is there a workaround for this issue at the moment? Would it be possible to construct an
ArrayBufferin .NET in a way that's not shared?fstanis commentedon Mar 4, 2025
I found a workaround by constructing a
JSTypedArray<T>manually fromMemory<T>:Hiwen commentedon Mar 17, 2025
I think this is a good solution for now.