Are reference types intended to always stay on a single thread?

[lachlansneff]

Since tables and globals (as far as I can tell) are not shared in the current threading proposal, are reference-types (and eventual gc-types) intended to always stay in a single wasm instance?

[chicoxyzzy]

Reference types are basis for GC types and interaction with threads is one of requirements for GC types

[titzer]

Agreed, we will eventually want to have references across threads. For the web embedding, however, it will not be possible initially, since tables and globals are not currently shared across web workers. The current thinking is to add a "shared" bit to both globals and tables which would indicate whether they would be duplicated or shared across threads, which would be supported in other embeddings of WASM.

[rossberg]

To expand on what @titzer wrote, to support shared references in the most general fashion we will need to extend the shared attribute that the threads proposal introduced for memories to tables, globals, functions, and reference types themselves. The type system will then ensure that only shared things are transitively reachable through other shared things. We have this generalised type system written out in a submitted research paper. We will make it public once it's through the double-blind review process next month or so.

As far as JS interop is concerned, regular JS values would continue to have non-shared reference type, so cannot be passed between threads.

[chicoxyzzy]

@rossberg will this remain true with presence of JS Typed Objects?

[rossberg]

@chicoxyzzy, good question. The typed object proposal might potentially be enriched with a similar attribute for defining types, which may allow respective objects to be shared. But there are a number of subtle problems to solve, e.g., what to do with prototypes or type identity.

[titzer]

Typed objects will have null prototypes in JS, but there @rossberg is right. There are a number of subtleties here that I suspect will cause more problems for JS, so it is reasonable to expect they will lag behind "pure" wasm objects for sharing. Which reminds me of a V8 implementation gotcha here...ergh

[rossberg]

Typed objects will have null prototypes in JS

@titzer, I'm afraid that's not what the TO proposal currently intends.

[lukewagner]

Typed objects will have null prototypes in JS

@titzer, I'm afraid that's not what the TO proposal currently intends.

As currently proposed, type objects would have a null prototype when created from an internal type definition. (See also the examples that show this difference.) So I think the abovementioned shared-ness rules in the type system, combined with instantiation-time checks, could indeed prevent shared type objects pointing to (necessarily un-shared) JS objects via __proto__.

[rossberg]

I think this has been answered.