State of concurrency support on wasm32-freestanding?

Got some time to look at this today and I believe it comes down to std.mem.Allocator calling @returnAddress in the member functions alloc, create, realloc, etc. The implementation of spawn defined in PosixThreadImpl uses std.heap.c_allocator and thus generates calls to @returnAddress. It seems that c_allocator just discards the return address parameter, so the call could likely be optimized out, but isn’t currently (maybe due to the vtable indirection).

The core issue seems to be that while emcc/llvm provide __builtin_return_address for Emscripten targets, it resolves to the expensive JavaScript function _emscripten_return_address. Currently any call to an Allocator interface is generating such a call out to JS.

1 Like