Closed flagxor closed 5 years ago
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 i32
s, 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:
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
)Promise
ctor, passing an executor Callback FunctionPromise.resolve
et alAs an addition, do we want to bind to existing WebAssembly atomic waiters, or existing JavaScript atomic waiters (potentially with the promise version of wait)?
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:
scope call
). This is the case for the Promise constructor, but can handle cases where the callback is called multiple times.scope async
). This is the case for the then
callback.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.@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".
@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 Are you talking about the proposed
waitAsync
? Since this just returns aPromise
, I think if we generally have a story for promises, we'd be able to bind towaitAsync
"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).
@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.
@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.
@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.
Closing as out-of-date: these concepts don't map to the current proposal, which has evolved a lot since this issue was opened.
@pchickey can you provide a link to the latest proposal?
Promises pervade the Web API surface. Perhaps we should provide some natural pattern for this.