Re: guile hoot and ArrayBuffer

[Thompson, David]

Hi Daniel,

On Sat, Jun 1, 2024 at 4:15 PM Daniel Skinner <daniel@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