Design: quando devemos precisar de um código de cola?

Qual código de cola? Você parece ter copiado aqui duas funções ( addThree() e adder() ) de alguns tutoriais do Wasm, talvez? Eles parecem simplesmente ser funções de exemplo que realmente não fazem muito e simplesmente servem para demonstrar um tutorial simples do Wasm. Nenhuma dessas funções tem uma assinatura complexa e deve ser chamada sem qualquer código de cola.

Mas, não é meu ponto. De alguns documentos, explica assim:

No longo prazo, o wasm com objetos digitados e GC podem ajudar. É isso que significa aqui?
Caso contrário, não tenho certeza de como esse código de cola pode ser removido a curto ou médio prazo. É muito trabalhoso formar um shell em torno de coisas C / C ++ que as façam parecer uma coisa JS. Por exemplo, o código cola deve conter métodos para converter uma string C em uma string JS e vice-versa. Em um nível C ++, o suporte à extensão de uma classe C ++ em JS e a implementação de métodos virtuais em JS exige um pouco de hackeamento. E, em geral, muita cola será necessária para acessar APIs da web de wasm por meio de JS.

e outros:

Emscripten requer uma grande variedade de código "cola" de JavaScript para lidar com a alocação de memória, vazamentos de memória e uma série de outros problemas, que já estão incluídos no modelo fornecido. É mais fácil usar isso do que ter que escrever tudo sozinho

Quando eu encontro algum código simplesmente C / C ++, eu poderia facilmente usar wasm compilando-o e export.xxxFn() .

int adder (int a, int b) {
    return a + b;
}

e quando eu uso código que usa Buffer, prefiro usar código cola.

# C/C++
int addThree(uint8_t *buf, int len) {
  uint8_t *item;
  uint8_t *end = buf + len;

  for (item = buf; item<end; item++) {
    *item += 3;
  }

  return 0;
}

# deal with buffer in JS
...
let dataHeap = new Uint8Array(Module.HEAPU8.buffer, dataPtr, nDataBytes);
dataHeap.set(new Uint8Array(buffer_pcm.buffer));
...

então, eu poderia concluir que quando eu transferir o Buffer para o WASM, preciso do código de cola para lidar com a alocação de memória, vazamentos de memória e uma série de outros problemas.

O código de adesão descrito no comentário acima é o carregador de JavaScript que o Emscripten gera. Ele faz exatamente o que o comentário diz: converte entre representações de dados JS e C ++ (por exemplo, strings) e entre diferentes representações de objeto (ou seja, criação de objetos proxy JS para objetos C ++). Ele também cria as matrizes digitadas necessárias.

Como você notou, você pode dispensar o carregador Emscripten para casos simples como as duas funções que você usou como exemplos. Nenhum deles requer qualquer código de cola complexo: cada um simplesmente precisa de um arquivo JS para carregar o arquivo Wasm (e no segundo exemplo, o arquivo wasm de addThree também precisará que o Uint8Array seja criado).

Finalmente, a alocação de memória é controlada pelo código Wasm, que deve incluir uma cópia do malloc do musl (embora o Emscripten ainda inclua seu malloc, na verdade, em vez de usar o musl). Vazamentos de memória são evitados da maneira padrão simplesmente liberando memória em seu código C / C ++ depois que você terminar de usá-lo, não há nada especial que o Wasm exija aqui.

Em última análise, você só precisa do código-cola que realmente usará, com base nas chamadas de fronteira cruzada que seu código faz (de JS para C ++ e de C ++ para JS).

Esse problema pode ser resolvido, é uma questão sobre o Emscripten, e não um bug no próprio design do WebAssembly.

muito obrigado