Replies: 1 comment 2 replies
-
You have to copy data once anyways, the ArrayBuffer is just a pointer to internal memory. That memory is not valid once you return from the callback, and certainly not for other threads. So copying to a SharedArrayBuffer if you need it, is already minimal. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I'm doing some early work around the use of uWebSockets in worker_threads. I'm doing a multicast like setup that will allow multiple workers to listen for messages (among other things).
Any thoughts on proving SharedArrayBuffers rather than ArrayBuffers if we option for it?
I think this could be a much more common need as developers evolve and start using more worker_thread oriented code.
Right now I'm converting to a SharedArrayBuffer if there is more than one interested party using a new SharedArrayBuffer instance along with a TypeArray instance (to copy the data with .set() ).
A single copy is made which does cut down the overhead (vs many copies), but it could be zero copies (lower latency) if the initial data was already in a SharedArrayBuffer.
Beta Was this translation helpful? Give feedback.
All reactions