Unexpected behaviour with async/await logic in JS host

[yourheropaul]

I'm building a WASM application that relies upon external, asynchronous operations carried out by the host. The WASM part must initiate an unknown number of requests by means of a function call to the host, and then await responses.

Awaiting promises is causing an issue, where the first value is always ignored

Context

I have this WASM code:

declare namespace operation {
    @external("operation", "call")
    function call(name:string): u32
}

declare namespace console {
    @external("console", "log")
    export function logs(val: u32): void;
}

export function myOperation(): void {
    console.log(1)
    const response = operation.call("some-name")
    console.log(4) // See below
    // Do something with response
}

Correspondingly, operation.call() is provided in the Node.js application using the loader:

export class WASMRumtime {
    protected api: ApiPromiseInterface
    protected module: ASUtil

    constructor(src: Uint8Array, api: ApiPromiseInterface) {
        this.module = instantiateBuffer(src, {
            env: {/* standard env config*/}.
            operation: {
                call: async (name: number) => {
                    console.log(2)
                    // This always returns a 0 value the first time
                    const v = await this.api.somePromiseReturningU32(this.moddule.__getString(name))
                    console.log(3)
                    return v
                }
            },
            console: { log: (value:number) => console.log(value) } }
        })
    }
}

Expected results

When myOperation() is called on the WASM, it should call operation.call() and get some value back. The first call is always a zero value, which is never returned by the promise in this case. Subsequent calls produce the previous value.

To try to understand what's happened, I've included some console.log() statements. I expected them to the called in numeric order, but they're not. The output to the console is:

1 <-- inside the WASM, before call to operation.call()
2 <-- inside the JS callback, before await
4 <-- inside the WASM, after operation.call() should have returned
3 <-- Inside the JS callback, after the await

Any idea why this might be?

Additionally, since function callback references and the table seem to have been disabled, is there any better way to get asynchronous data from the WASM host on demand?

[MaxGraey]

You try do some continuation (interrupt wasm execution by host code and come back later in the same frame with continue execution). That's not work in WebAssembly without extra efforts. See this experimental PR which describe pretty simple example usage of Binaryen's Asyncify. But this required latest Binaryen which not yet landed

[yourheropaul]

Thanks, I'll try that out!

Is there any other way of achieving a callback function, given that the Table is removed?

[MaxGraey]

You could use table. Just add --importTable flag and create it in env: { table: new WebAssembly.Table({ initial:1, element:"anyfunc" }) }

[yourheropaul]

--importTable during compile time solves the problem for my use case, thanks!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.