Add Thread-Bound Data to the documented JS API #53
Conversation
As discussed in #30 and #37, add a JS API that allows arbitrary objects to be wrapped and converted to shared externrefs with dynamic checks ensuring the wrapped object is only ever observed on the original thread. Refer to the existing FAQ entry for discussion on how the lifetimes of the wrapper and wrapped object might interact. Resolves #37.
| @@ -589,6 +589,26 @@ entire thread or agent. | |||
| [jspi]: https://github.com/WebAssembly/js-promise-integration | |||
| [realm]: https://tc39.es/ecma262/#realm | |||
|
|
|||
| #### Thread-Bound Data | |||
|
|
|||
| Just as WebAssembly produces expect to be able to call JS functions, they also expect to be able to | |||
There was a problem hiding this comment.
Users?
| Just as WebAssembly produces expect to be able to call JS functions, they also expect to be able to | |
| Just as WebAssembly users expect to be able to call JS functions, they also expect to be able to |
| references to DOM nodes in some of its shared objects. Normally this would be disallowed because DOM | ||
| nodes are not shareable and shared-to-unshared references are disallowed. To bridge this gap, we | ||
| need a utility that allows shared-to-unshared objects as an exception to the general rule, assuming | ||
| that Web GCs can support such an exception (see the discussion in the FAQ below). To avoid |
There was a problem hiding this comment.
| that Web GCs can support such an exception (see the discussion in the FAQ below). To avoid | |
| that browser GCs can support such an exception (see the discussion in the FAQ below). To avoid |
|
|
||
| `ThreadBoundData` is a shared JS object that wraps any other arbitrary JS object. `ThreadBoundData` | ||
| provides access to the wrapped object via a `get` method that throws an exception when called on any | ||
| thread besides the thread that owns the wrapped object, ensuring that the wrapped object can be |
There was a problem hiding this comment.
When we say "thread" here, do we really just mean web workers? It might be worthwhile clarifying that...
There was a problem hiding this comment.
+1 we should be more precise. In specese that would be "agent".
There was a problem hiding this comment.
Is a function called on an agent or called by an agent?
| #### Thread-Bound Data | ||
|
|
||
| Just as WebAssembly produces expect to be able to call JS functions, they also expect to be able to | ||
| hold handles to JS objects. For example, a language compiled to shared WasmGC may need to hold |
There was a problem hiding this comment.
| hold handles to JS objects. For example, a language compiled to shared WasmGC may need to hold | |
| reference JS objects. For example, a language compiled to shared WasmGC may need to hold |
| nodes are not shareable and shared-to-unshared references are disallowed. To bridge this gap, we | ||
| need a utility that allows shared-to-unshared objects as an exception to the general rule, assuming | ||
| that Web GCs can support such an exception (see the discussion in the FAQ below). To avoid | ||
| complicating the core language and forcing every non-Web engine to support shared-to-unshared edges, |
There was a problem hiding this comment.
| complicating the core language and forcing every non-Web engine to support shared-to-unshared edges, | |
| complicating the core language and forcing every engine to support shared-to-unshared edges, |
|
|
||
| `ThreadBoundData` is a shared JS object that wraps any other arbitrary JS object. `ThreadBoundData` | ||
| provides access to the wrapped object via a `get` method that throws an exception when called on any | ||
| thread besides the thread that owns the wrapped object, ensuring that the wrapped object can be |
There was a problem hiding this comment.
Unclear what "owns" means. I'm guessing you mean "created"?
There was a problem hiding this comment.
Will clarify that it is the agent on which the ThreadBoundData wrapper is created. (As opposed to the agent on which the wrapped object was created, in case someone wants to wrap a shared object for some reason.)
|
|
||
| `ThreadBoundData` is a shared JS object that wraps any other arbitrary JS object. `ThreadBoundData` | ||
| provides access to the wrapped object via a `get` method that throws an exception when called on any | ||
| thread besides the thread that owns the wrapped object, ensuring that the wrapped object can be |
There was a problem hiding this comment.
+1 we should be more precise. In specese that would be "agent".
|
Thank you both for the review. I've addressed all the feedback. I'll also add this as an agenda item for the next subgroup meeting. |
|
The text here already includes "... assuming that browser GCs can support such an exception (see the discussion in the FAQ below)" so I think it's sufficiently clear that this is not set in stone and depends on architectural constraints from browsers. |
|
Talked to @eqrion: he has opinions on this but is on leave for a few more weeks. Why don't we leave it open until he gets back? |
|
(sorry for the delay, just got back). My comment was only just ensuring that this is suitably marked as depending on browsers supporting shared-to-unshared references, which is an open question at this point. It looks like that's marked out well enough, so I think this can be merged. |
As discussed in #30 and #37, add a JS API that allows arbitrary objects to be wrapped and converted to shared externrefs with dynamic checks ensuring the wrapped object is only ever observed on the original thread. Refer to the existing FAQ entry for discussion on how the lifetimes of the wrapper and wrapped object might interact.
Resolves #37.