Interface Types and Isolation?

[kripken]

Is Interface Types an isolation mechanism, or an interfacing mechanism? @tlively and I were surprised to hear from @fgmccabe that a wasm module using IT should not be able to share its memory with other modules, which led to some discussion and now this issue.

An example of a concrete use case for sharing memory: Imagine a game engine that has some compiled script language code as well (e.g. the engine might be C++ and the script language could be C# or Python). It might be nice to link the compiled game engine and the compiled script code and hook them up using IT. But in this case we'd want to share large amounts of memory between them, for example a script plugin might render the game's UI, or generate audio samples. We would want to use IT to avoid the engine rolling its own string, array, etc. conversions and just use IT there, but we would not want to use it for everything. For large binary data we'd like to just share memory (and are willing to take the risks).

More generally, we would like to allow Interface Types to be used for some interactions between two modules while preserving the ability for those two modules to drop down to the current style of coordination for other interactions.

Thoughts?

[lukewagner]

I think IT should allow modules to isolate themselves, but it's not clear that IT should require it by actively preventing modules from importing or exporting memory; that seems a bit paternalistic.

That being said, isolation seems especially valuable in the context of a scripting engine. And even when large buffers are at play, there is usually a copy happening somewhere (e.g., out of a JS typed array and into a WebGL resource), so it seems like one could often achieve isolation and efficiency by having the copy happen at the isolation boundary.

[jgravelle-google]

One of the core advantages I can see Interface Types having is the ability to non-paternalistically add convenience+sanity to module boundaries. To that end, my intuition says we absolutely should allow exporting memory through IT.

I am starting to worry about what a world where people DO share memory via IT looks like. It sounds like "I want to use these foreign APIs that I don't know about, but everyone else should be fine accessing my ABI" in the worst case, which if everyone does that would be sub-good. Though the more likely case is "I want to use and publish convenient APIs, but for huge data structures direct access is too important to give up". Memory slices is probably how we solve that problem more-goodly, but raw memory can work as a stopgap.

Also we really can't prevent people from having the capability to mess around with memory if the module wants them to. If we disallow people from exporting memory directly, they can always export memory accessor functions that do the same things, only less efficiently. In general I don't think we'll be able to remove any core wasm capabilities, and we probably shouldn't try to.

[fgmccabe]

Yes, that 'spreading the memory' disease also worries me. There is a better alternative: memory views. It is better for two main reasons: it accounts for more use cases than just sharing memory and there is much less expectation of having the equivalent of malloc/free for the region within the view; i.e., it is more obviously a buffer for raw-ish data. It is also not quite as performant as sharing memory. Noone is going to put large guard pages around a view.

Francis

On Thu, Mar 12, 2020 at 5:15 PM Jacob Gravelle notifications@github.com wrote:

One of the core advantages I can see Interface Types having is the ability to non-paternalistically add convenience+sanity to module boundaries. To that end, my intuition says we absolutely should allow exporting memory through IT.

I am starting to worry about what a world where people DO share memory via IT looks like. It sounds like "I want to use these foreign APIs that I don't know about, but everyone else should be fine accessing my ABI" in the worst case, which if everyone does that would be sub-good. Though the more likely case is "I want to use and publish convenient APIs, but for huge data structures direct access is too important to give up". Memory slices is probably how we solve that problem more-goodly, but raw memory can work as a stopgap.

Also we really can't prevent people from having the capability to mess around with memory if the module wants them to. If we disallow people from exporting memory directly, they can always export memory accessor functions that do the same things, only less efficiently. In general I don't think we'll be able to remove any core wasm capabilities, and we probably shouldn't try to.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/WebAssembly/interface-types/issues/99#issuecomment-598487124, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQAXUA5NK34F2ISE57ZLG3RHF3JNANCNFSM4K56PARA .

-- Francis McCabe SWE