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
Add ability to Share Native Object Instances between Main and Worker Runtimes #37
Probably doesn't even need the global functions. At least on V8 you can just implement the method that deals with serialization/deserialization and check if it's a custom object or not
@edusperoni For napi runtimes we need something that will work across the board on all js engines. Also sharing native objects should be explicit instead of passing an object that may or may not contain a reference to some native object.
I don't think that's how it works on the web though. Main example being ArrayBuffer vs SharedArrayBuffer. Those can be sent as messages to workers, but one is copied and the other is shared, you don't need to explicitly say which is copied and which isn't.
We cannot use or follow Transferrable Objects API since it's meant to transfer the ownership of the underlying data, in our case we are simply copying reference to a native object.
But it will require doing a deep check on any object passed into postMessage which will slow down sending data to workers even when you are not passing any native object. For example:
You only get implemented native methods (you receive the native class with no access to JS parts). Of course, any calls to JS implemented methods would lock the other isolate
I'm not sure which would be best, as both seem bad haha
I think once we implement basic object sharing we can figure out rest of the cases and fine tune the API. Currently in NAPI runtime extended classes are bound to invoke callbacks into the runtime. The JS Part can't be transferred obviously. Only the native part.
Activity
edusperoni commentedon Nov 29, 2025
Probably doesn't even need the global functions. At least on V8 you can just implement the method that deals with serialization/deserialization and check if it's a custom object or not
ammarahm-ed commentedon Nov 30, 2025
@edusperoni For napi runtimes we need something that will work across the board on all js engines. Also sharing native objects should be explicit instead of passing an object that may or may not contain a reference to some native object.
edusperoni commentedon Nov 30, 2025
I don't think that's how it works on the web though. Main example being ArrayBuffer vs SharedArrayBuffer. Those can be sent as messages to workers, but one is copied and the other is shared, you don't need to explicitly say which is copied and which isn't.
See https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Transferable_objects
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer
ammarahm-ed commentedon Nov 30, 2025
We cannot use or follow Transferrable Objects API since it's meant to transfer the ownership of the underlying data, in our case we are simply copying reference to a native object.
This looks good:
But it will require doing a deep check on any object passed into postMessage which will slow down sending data to workers even when you are not passing any native object. For example:
It may also result in accidentally sharing references to the worker that you may not need at all.
It can work if it's just limited to this:
ammarahm-ed commentedon Nov 30, 2025
I also wanted to ask what happens if someone shares a native class extended on the main runtime to worker runtime or we won't be supporting those?
What will happen in this case? @edusperoni
edusperoni commentedon Nov 30, 2025
I see this as 2 possible options:
I'm not sure which would be best, as both seem bad haha
ammarahm-ed commentedon Nov 30, 2025
I think once we implement basic object sharing we can figure out rest of the cases and fine tune the API. Currently in NAPI runtime extended classes are bound to invoke callbacks into the runtime. The JS Part can't be transferred obviously. Only the native part.