One top-level shared flag instead of granular shared flags per-type

[alexcrichton]

I've been talking with @abrown about this proposal and thinking about some high-level details about how it might be implemented in Wasmtime. Nothing is concrete yet and it's clear that lots of internals in Wasmtime need to be redesigned for this proposal in addition to the embedding API. One thing that I've been thinking about though is whether it would suffice to change the proposal to avoid adding shared tags on all types and instead have a single shared tag at the module level. For example instead of

(module
  (type $shared (func shared))

  (func $baz (import "env" "baz") (type $shared))

  (func $bar (type $shared)
    call $baz
  )
)

it would instead be:

(module shared
  (type $shared (func))

  (func $baz (import "env" "baz") (type $shared))

  (func $bar (type $shared)
    call $baz
  )
)

The theory would be that within a shared module everything behaves exactly the same as the current state of the proposal if all types/globals/funcs/etc were all tagged shared. So in that sense I'm not thinking that this would not be a runtime-wise semantic change. The major change, relative to the current proposal, is that module can no longer declare both shared and unshared things internally and use them, except of course for core wasm today which can work with a shared memory (through the prior threads proposal).

I realize that this would be a radical rethinking of the current proposal. I also realize that it would be a pretty significant shift in course from prior thinking. I also realize that use cases which rely on intermixing shared and unshared things may not work. In that sense I wanted to start a discussion on this and see where it goes. Some benefits of this approach that I've been thinking are:

• My impression is that toolchains are basically going to operate in either shared or unshared mode. For example I'm under the impression that LLVM (I could be wrong here) would either have everything shared or everything not shared. If other toolchains follow suit (again please tell me if my thinking is wrong here) then in practice there may be very little usage for shared-and-unshared in the same module. If this ends up being the case then a top-level flag might be a simpler solution.
• If a use case for using both shared-and-not-shared things only goes through a shared memory, then wasm today (which is unshared) can already import shared memory and operate on it. With a system like this a hypothetical single module with both shared and unshared things inside which coordinate through a shared memory could be two modules instead. One is a shared module with all the shared bits and one is an unshared module with all the unshared bits plus the shared memory used for coordination.
• I'll emphasize that the thinking here is extremely early on and is missing concrete details, but a hypothetical embedding API for Wasmtime which supports this proposal could be relatively awkward without shared modules. For example today in Wasmtime you start with a Store which is used to create an instance. A Store, however, is effectively a single-threaded thing and can only be used on one thread at a time. This is in contrast with shared things which want to be used on multiple threads at the same time. That means to get a SharedFunc (again, a hypothetical) you'd have to create a single-threaded Store, create an Instance which is bound to that Store, then acquire a Func as an export, then cast that to a SharedFunc, then move that to other threads and work with it. This is in contrast with a hypothetical shared module where in Wasmtime we'd represent that at the type level (e.g. a SharedModule as opposed to a Module which would have a different instantiation process which may not deal with a Store.

I'll reiterate again as well that I realize this would be a radical change of pace for this proposal. That being said if a change like this were ever to be made this is probably the time to do it. So in that sense I wanted to test the waters a bit and throw this out there and see what others thought. I do not personally understand all the intricacies of threading on the web for example and would be eager to hear more about how that means this could never work or things like that.

[conrad-watt]

Apologies for throwing out a short comment - I'll try to digest this more thoroughly in the meantime.

The standard knee-jerk argument against such a module-level flag is that it interferes with our ability to merge already-compiled modules (e.g. see WebAssembly/binaryen#5709). For example if I build a program involving an unshared module that calls a shared module (which may have been separately compiled), for optimisation/deployment/distribution purposes I may want to merge these two modules together into one bigger module, but this wouldn't easily be possible if "sharedness" could only be marked at module granularity.

[rossberg]

What @conrad-watt said. As I have argued on multiple occasions, no semantics should ever be tied to module scopes. Modules are merely a grouping mechanism for definitions, and regrouping (splitting/merging modules) should always be possible without restrictions.