Hi Daniel, On Sat, Jun 1, 2024 at 4:15 PM Daniel Skinner <dan...@dasa.cc> 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