WebAssembly/threads

Is it possible to write to memory in Nightly and read same memory in Chromium?

Closed this issue · 7 comments

Initializing Memory Only Once

The data segments are always copied into linear memory, even if the same module is instantiated again in another agent.

The specification states that data segments are always copied into linear memory.

The use case for writing to memory in Firefox and read same memory in Chromium is to avoid using the current approach of writing and reading to clipboard in order to establish a WebRTC peer connection to stream audio from Nightly to Chromium https://gist.github.com/guest271314/04a539c00926e15905b86d05138c113c.

Is it possible to read data segments written from Nightly at Chromium?

Are you asking if a reference to a single WebAssembly memory could be shared between two different browsers? It's likely this will never be possible for a variety of reasons, not least that the browsers will implement memory in different ways, and so can't share a consistent view of a single allocated memory.

I'm not completely familiar with WebRTC, but it looks like a "signaling server" must normally be used to allow two peers to exchange SDP information. On a local machine, you could investigate running a local signaling server (as suggested here), but the clipboard approach is actually probably a pretty light-weight way to solve the problem.

Are you asking if a reference to a single WebAssembly memory could be shared between two different browsers?

Yes. That is what is possible to be inferred by the definition of the term agents used

When memory is shared between agents, modifications to the linear memory by one agent can be observed by another agent in the agent cluster.

and the language at Overview.md https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md#initializing-memory-only-once, specifically

even if the same module is instantiated again in another agent.

if we write to linear memory at Nightly, then stop, we should be able to read that data by some means short of disk forensics and recovery procedures, at Chromium.

If that is not the case can you kindly update Overview.md to remove the potential for literal interpretation of

even if the same module is instantiated again in another agent.

given a user in the field might have such a use case.

but the clipboard approach is actually probably a pretty light-weight way to solve the problem.

That approach does work. Requires not using the clipboard in the interim, which actually does occur in this case as launch Nightly before Chromium at the command line, though there is still the case of having text editor open and making a minor change in an open project by copy and pasting that could affect the procedure. Ideally this can be achieved without prompts (have not yet found a way to disable prompting for clipboard access at Chromium). If Nightly supported Native File System would simply write the data to local files - which would also require prompts. Prompts are not that much of an issue, though does eliminate the possibility of complete automation.

Yes, can use a server, and, or Native Messaging to achieve the task. In general, first attempt to create workarounds at file: protocol, using only API's shipped with the browser, then if the requirement is not possible otherwise, use shell scripts; e.g., a different workaround for the same use case, using bash, php, and Native Messaging. Read the linked answers recently. Will re-read.

@conrad-watt The workaround using a server wasmerio/wasmer-php#121. Where essentially the same question is asked: Is it possible to write to WebAssembly (WASM) memory from php?

"agent" and "agent cluster" have technical meanings that are inherited from Javascript's SharedArrayBuffer spec. In this scenario, the workers running in separate browsers cannot be part of the same agent cluster.

Given the case of presumptive current impossibility of writing to memory in one agent cluster and reading that same memory in a different agent cluster, how would you go about reading the memory written in a different agent cluster anyway, to prove that doing so is impossible; and if the result is in fact proof of impossibility, how would you go about specifying that procedure be made possible?

If we can write to the clipboard at an application, or "agent" in an "agent cluster" and get that data at a different application, "agent" or "agent cluster", we should be able to write to and read from the same linear memory across applications; even if clipboard access is just the simplest way to achieve the requirement considering the implied restrictions from accessing data across "agent clusters".

If we can write to the clipboard at an application, or "agent" in an "agent cluster" and get that data at a different application, "agent" or "agent cluster", we should be able to write to and read from the same linear memory across applications

This doesn't follow. The clipboard here is effectively being used as an OS-mediated channel. The text is copied from the browser into the clipboard, not passed by reference. To share a memory directly, both browsers would need a mechanism for sharing the same reference to a single memory allocation.

You should focus on other ways of accomplishing your goal. Maybe you could replace your Firefox instance with a locally running server that the Chrome instance connects to, rather than using peer-to-peer. Alternatively, maybe there's some utility that can create a "fake" relaying audio device that Chrome can recognise. In any case, this problem is well beyond the scope of this repository.