Binding type for Promises?

[flagxor]

Promises pervade the Web API surface. Perhaps we should provide some natural pattern for this.

[lukewagner]

Yeah, we should strive to integrate well with promises. I think the core missing functionality from the current proposal is an argument/return binding for passing a Callback Function. I imagine this binding would take a pair of i32s, interpreting the first as an index into a Table (of anyfunc) and the second as the usual void* closure argument bound to the first argument.

With this, we could:

• import Promise.prototype.then and call with mode CALL_THIS, passing a Promise (via OBJECT_HANDLE) as receiver and then one or two Callback Functions (as onFulfilled/onRejected)
• import the Promise ctor, passing an executor Callback Function
• import Promise.resolve et al

[jfbastien]

As an addition, do we want to bind to existing WebAssembly atomic waiters, or existing JavaScript atomic waiters (potentially with the promise version of wait)?

[magcius]

Callbacks are trickier than first imagined -- the biggest issue is knowing when you can free the void* user_data pointer. In GObject Introspection, we identified and added three main patterns:

• Valid for the duration of the call. (scope call). This is the case for the Promise constructor, but can handle cases where the callback is called multiple times.
• Valid until the first callback (scope async). This is the case for the then callback.
• Valid until further notice (scope notified). This requires an extra callback to know when void* user_data can safely be freed without issues. This would be required for addEventListener or similar -- the callback would be called when the object is destroyed, or when removeEventListener for that callback is called.

[lukewagner]

@jfbastien Are you talking about the proposed waitAsync? Since this just returns a Promise, I think if we generally have a story for promises, we'd be able to bind to waitAsync "for free".

[lukewagner]

@magcius That's a great point. I think for the first two bullets, we can solve the problem at the toolchain level, because we know when to call dtors/free. For the last bullet though, you basically need some form of finalizer or postmortem notification. That is definitely something we've talked about proposing in general (as a JS+wasm feature) for a number of reasons. When we have that feature, it makes sense to offer another version of the Callback Function binding that allows a third i32 which is an index into a Table<anyfunc> of a callback to call when the Callback Function is finalized. Until then, I think we'll be limited to only supporting the first two bullets.

[jfbastien]

@jfbastien Are you talking about the proposed waitAsync? Since this just returns a Promise, I think if we generally have a story for promises, we'd be able to bind to waitAsync "for free".

Yeah! What I mean is that it would be neat for all the WebAssembly-to-JS-promise things to work approximately the same.

Which makes me think that we probably also want to do the same for C++ promises (however they end up looking, whether it be mutex, async, or some C++20 executor / future thing).

[lukewagner]

@jfbastien Yeah, makes sense. An interesting question is whether promises stay forever as generic host bindings or we attempt to "internalize" promises in a more significant way into core wasm. Probably we'd start with generic host bindings and see if there are any unsolvable issues.

[jfbastien]

@lukewagner through atomic wake / wait we have something that can back promises. What I'm wondering is if we want to make it easy to bridge WebAssembly promises (in C++ or whatever) to embedder promises. In some cases they can use the same backing futex / parkinglot / WaitOnAddress / etc, and in others we'd need the bindings to bridge between the two seamlessly.

[lukewagner]

@jfbastien Are you talking about what if we wanted to add some wait_async wasm op that was equivalent to JS's proposed Atomics.waitAsync? In that case, we'd have a core wasm op produce a promise-y thing so yeah, it would make sense to try to unify this with host promises. I don't imagine we'll want to do this any time soon, though.

[pchickey]

Closing as out-of-date: these concepts don't map to the current proposal, which has evolved a lot since this issue was opened.

[chcunningham]

@pchickey can you provide a link to the latest proposal?