Design: Wasmroutines

A proposta de threads de WebAssembly existente se concentra em permitir que o programa compilado wasm utilize vários threads de sistema. Este é um recurso extremamente útil para tarefas intensivas da CPU. Porém, há uma grande classe de problemas que exige muito IO e é mais bem resolvida por corrotinas muito mais leves do que as roscas do sistema. A recente adição do Rust async-wait a uma linguagem que já oferece suporte a multithreading é um bom exemplo dessa necessidade. O problema com async-await é que ele requer uma maneira completamente diferente de escrever o código do aplicativo, bem como diferentes técnicas de compilação. Por outro lado, uma das principais razões para a popularidade do Go são as goroutines, que parecem threads reais para o desenvolvedor, enquanto são executadas como co-rotinas pelo tempo de execução.
Eu acredito que o WebAssembly está posicionado de forma única para trazer a vantagem do modelo de threading Go para praticamente qualquer aplicativo multithread que possa ser compilado para o wasm. A ideia é que o programa compilado não precise mudar para alavancar os fios verdes, isso se torna a escolha do host sobre como executá-lo.
Outro recurso importante do WebAssembly é a execução determinística. Com threads verdes, deve ser simples implementar o modo de execução determinístico para destinos multithread.
O nome do espantalho para o recurso é _Wasmroutines_.

Encontrei alguns problemas relacionados a "threads de wasm nativos", como https://github.com/WebAssembly/design/issues/126 e https://github.com/WebAssembly/design/issues/1252, mas parece que são considerado como algo que poderia chegar eventualmente, mas bastante teórico neste ponto.

Eu acredito que a _implementação de thread de sistema único_ pode ser feita com esforço relativamente pequeno (por exemplo, poderia usar a memória linear normal) e forneceria muito valor (como executar qualquer programa multithread sem modificação) que vale a pena ter como um design separado proposta.