Well, we'll make do in the meantime; thanks for the explanation! On Sat, Jun 1, 2024, 5:01 PM Thompson, David <[email protected]> wrote:
> Hi Daniel, > > On Sat, Jun 1, 2024 at 4:15 PM Daniel Skinner <[email protected]> wrote: > > > > I'm wondering if it's possible (or on the roadmap, or if the question is > > even sane) to have the various bytevector functions operate upon passed > in > > ArrayBuffer. > > Not currently possible, unfortunately. Wasm GC has some growing to do > in order to support this use case. What is needed is a way to view a > heap array, such as (ref (array i8)) which is what bytevectors use > under the hood, as an ArrayBuffer from JS. There are implications for > the Wasm security model, though, because right now all Wasm heap types > are opaque to the host. This is why to copy a bytevector from Wasm to > JS you have to copy it over byte by byte... bleh. > > > Or is there some manner to provide a view of a bytevector as an > ArrayBuffer > > from the default wasm memory in use. > > > > For example, referencing below I mean to create the memory in JS and then > > operate upon it in hoot module: > > > https://developer.mozilla.org/en-US/docs/WebAssembly/JavaScript_interface/Memory > > > > Specifically, there is this section which I'm wondering if supported in > > some fashion: > > """ > > Originally you could only perform memory operations on a single memory in > > the Wasm module, so while multiple Memory objects could be created, there > > wasn't any point doing so. More recent implementations allow WebAssembly > > memory instructions to operate on a specified memory. For more > information > > see Multiple memories in Understanding WebAssembly text format. > > """ > > Hoot doesn't use the linear memory model. Unfortunately, memory > objects are the only objects for which you can access as an > ArrayBuffer from JS right now. This gives languages targeting linear > memory an advantage over GC languages. > > > The actual problem I'm trying to solve is an area of memory with one > writer > > and many readers that may span worklets. I could solve this in a number > of > > inefficient copy methods but something along the lines of above seems > like > > a better choice. > > > > See also this comment which seems desirable: > > https://github.com/WebAssembly/design/issues/1231#issuecomment-420466909 > > Unfortunately it doesn't appy to Hoot. > > > Currently I'm doing the following within a single worklet which isn't > even > > the more complicated case above and wondering if necessary: > > > https://codeberg.org/dskinner/shields-tyvm/src/commit/01130104d18a50367d839a639d12895f43298ec8/realtime_worklet.js#L792 > > This is basically the same thing we have to do to copy over strings > when they cross over to JS. It's terrible! > > > https://gitlab.com/spritely/guile-hoot/-/blob/main/reflect-js/reflect.js?ref_type=heads#L378 > > The problem could be solved for strings, at least, if the stringref > proposal would be adopted. Unfortunately, it has faced a lot of > opposition and we've had to settle for workarounds. > > There's a Wasm CG meeting coming up this month that I plan to attend > remotely and I'll see if anything comes up about this issue. You want > to do realtime audio. I want to do realtime graphics. We need to be > able to efficiently handle blobs of binary data! > > In solidarity, > > - Dave >
