how does --asyncify handle locals in the memory?

[ghost]

When I have code like the following, the local has to be stored within a stack in the memory so that it can be referred to from xxx (bar inlining). Does --asyncify handle this well? And how does it know where the stack is in the memory?

void foo(void)
{
   int a;
   xxx(&a);
   printf("%d\n", a);
}

[ghost]

I have just found this piece of code:

binaryen/src/wasm/wasm-emscripten.cpp

Lines 55 to 58 in d3f2df3

	// Assumption: The stack pointer is either imported as __stack_pointer or
	// we just assume it's the first non-imported global.
	// TODO(sbc): Find a better way to discover the stack pointer. Perhaps the
	// linker could export it by name?

Is this assumption also used by --asyncify to determine where the stack is in memory?

[kripken]

Asyncify handles this kind of thing automatically, but it does so without any special knowledge of the ABI of the C stack (which is what the LLVM-related code in wasm-emscripten does). Instead, Asyncify just saves all the locals when it pauses, and restores them all when it resumes. That includes a local that happens to store the stack pointer. And the C stack will only be unwound after execution resumes, so no problem should occur.

(However, if you use something like fibers where multiple things are switched between, then you'd need to do something like manually copy the C stack. In emscripten the Fibers API is implemented that way, on top of Asyncify.)

[ghost]

Ah, I see! Could this have been the cause of the issue I was running into in #4905? As far as I understand, what I was calling “coroutines” then were actually “stackfull coroutines” (fibers), which is what I actually want to be able to use in my program.

Though does that mean that it is (in theory) not possible to have multiple calls into Wasm code happening at the same time without having to be aware of the stack implementation? Imagine e.g. I call from JavaScript into a Wasm function, which calls sleep, and while that function is sleeping, I call a different Wasm function. Is that use‐case not supported?

[kripken]

I think it could be supported, but how depends on the details.

Just calling into a second wasm function while another is sleeping is ok, so long as the second function just does some computation and then exits, that is, it does not sleep itself. Assuming the normal LLVM stack behavior, the second function will grow the stack and then shrink it back, so when the sleeping function resumes, it can't even tell anything ran in the middle.

That might not be ok if the program assumes, at a higher level, that no code runs while sleeping. But without such problems it can work ok. In Emscripten this use case happens, for example, if you do an async network fetch. While sleeping we finish the fetch and then call into the wasm to do a malloc so we have space to write it to. That malloc is fine to call even though we are asleep.

If you do want to sleep in the second function (while another is asleep), and swap between them in a mixed way, then you need integration at a level that understands the stack. Here is a key part of the emscripten code that does that for the Fibers API:

https://github.com/emscripten-core/emscripten/blob/0ced16e037d4d0dc43f9176db4fbdeb3b79d2df1/src/library_async.js#L569-L578

That calls into the wasm to set the stack position (using _emscripten_stack_set_limits), and then it restores the previous stack (using stackRestore).