Victor Adossi (Jan 22 2025 at 18:05): Victor Adossi (Jan 22 2025 at 18:05):To follow up on what we discussed very briefly in the Jco meeting today towards P3, I reached out to @Joel Dice and he kindly answered:
Yeah, so there are really three export ABIs:
- Synchronous: cannot reenter until it returns
- Asynchronous, with a callback: cannot reenter until it "returns", but note that "returns" here doesn't mean it's done. It might be done or might just be unable to make more progress until one or more of its waitables have made progress, at which point the host will call its callback. The latter can happen multiple times, concurrently with other in-progress tasks. In this case, there's only ever one Wasm stack involved.
- Asynchronous, without a callback: can be reentered on a new stack concurrently (but not in parallel!). In this case there can be as many stacks as there are outstanding tasks.
Yeah, I expect Rust, C#, JS, and Python (i.e. the async/await languages) will use the second one, and e.g. Go and Java (the ones with stackful coroutines/fibers) will use the third one.
Hopefully I was able to repeat what you were intending correctly @Till Schneidereit but I noted that what you plan on using is approach (3)
@Yosh Wuyts @Tomasz Andrzejak @Calvin Prewitt
Till Schneidereit (Jan 22 2025 at 18:16):thank you for the follow-up!
I actually plan on using (2): asynchronous with callbacks. That's why this isn't reliant on JSPI support: there won't ever be multiple stacks involved. It's also a much better fit for JS semantics, because JS expects run-to-completion, not stack suspension
Victor Adossi (Jan 22 2025 at 18:20):Ah right, Joel's note was right there -- I remembered the C API note and callbacks but noted the wrong one, thanks for the clarification.
To reiterate where we got to on the call, the JSPI/Asyncify stuff is only important for host primarily -- C API w/ async + callbacks for guests using StarlingMonkey
Till Schneidereit (Jan 22 2025 at 18:22):right, yeah. Or to put it another way: JSPI (or asyncify) is required to implement (3), and thus important for JCO to support all ABI variants, but it's not required to support specifically StarlingMonkey based components
Calvin Prewitt (Jan 22 2025 at 19:09):JSPI (or Asyncify) on the JCO host might be also required to implement much of (1) Synchronous, to use the Web APIs that are async and we need the ability to block and suspend the Wasm execution.
Joel Dice (Jan 23 2025 at 20:30):Hi all. I chatted with @Till Schneidereit and @Luke Wagner about WASIp3 implementation logistics today and the TL;DR is that we do not need to support the async-without-callback ABI for 0.3.0.
We won't need it for StarlingMonkey-based guests according to Till, and TinyGo won't use it for the foreseeable future, so (as far as we know), there won't be any guest toolchains that use that ABI in the short-to-mid term, meaning there's no urgency to support it in 0.3.0. I've already implemented it in Wasmtime, so no point in backing that out, but I don't think we need it in Jco, and thus no need for JSPI or Asyncify AFAICT.
To be clear, we do want to support that ABI post-0.3.0, but it's no longer a blocker for 0.3.0.
Joel Dice (Jan 23 2025 at 20:33):Put another way: the Worker-thread-based hack we used to support wasi:io/poll in Jco for WASIp2 should still be sufficient for 0.3.0. If folks are eager to remove that hack anyway, I won't try to talk them out of it, but I don't think that's needed for 0.3.0.
Alex Crichton (Jan 23 2025 at 21:04):I don't think we need it in Jco, and thus no need for JSPI or Asyncify AFAICT.
I think this is still required for blocking APIs though? For example if a wasm module blocks on the result of a future that'll require JSPI to implement?
Alex Crichton (Jan 23 2025 at 21:04):oh but I suppose that could use the same hack as before
Calvin Prewitt (Jan 23 2025 at 22:13):For Jco, you could think of the JSPI / Asyncify implementation as an alternative to the hack using Workers and atomics.
Joel Dice (Jan 27 2025 at 15:24):Thinking about this some more, we still do need to be able to manage multiple Wasm stacks concurrently in order to support async->sync calls (i.e. we need to support an async-lowered import of a sync-lifted export such that the caller can continue to make progress while the callee is blocked, which requires multiple Wasm stacks). Not sure if the Worker-thread-based approach can accommodate that.
Victor Adossi (Jan 27 2025 at 15:38):Yosh's meeting notes:
https://hackmd.io/@yoshuawuyts/HkDpwmrukg
Luke Wagner (Jan 27 2025 at 16:11):@Joel Dice hypothetically one could put each component instance in a separate worker, making cross-worker calls for the async->sync call (analogous to when JS-main-thread calls into the worker, but originating in the worker), but obviously not ideal performance
Joel Dice (Jan 27 2025 at 16:12):Many of us are in a meeting talking about this right now. @Calvin Prewitt expects JSPI/Asyncify support to be merged into Jco within the next couple of weeks, so we might not need to deal with worker-related pain.
Calvin Prewitt (Jan 27 2025 at 17:04):Victor Adossi said:
Yosh's meeting notes:
Added the recording link to the meeting notes.
Victor Adossi (Jan 27 2025 at 17:15):@Till Schneidereit
Victor Adossi (Jan 27 2025 at 17:16):I may have been misunderstanding though -- this may not be terribly relevant to you Till but Joel's excellent walkthrough/explanation of the complicated cases and the callback vs non-callback impl
Victor Adossi (Jan 27 2025 at 17:19):(also for now keeping the guest side separate for now is of great importance, but I thought you might benefit from the explanation in there of the APIs)
Till Schneidereit (Jan 27 2025 at 17:20):thank you for the additional context, Victor!
Till Schneidereit (Jan 27 2025 at 17:21):as long as JSPI is on track, I think everything is great. If that runs into any snags, that would be good to know sooner rather than later though, because we'd have to reevaluate our options in that case
Last updated: Feb 27 2025 at 22:03 UTC