Amber (Mar 31 2025 at 16:45): Amber (Mar 31 2025 at 16:45):Hey all! First time opening a thread here, also my first time using Zulip... I appreciate any patience with any error I make opening this thread :).
I've been lurking and working on wasip3 support as a consumer of wasmtime for a project of mine, and I've been exploring adding p3 support to the rust libc (and thus wasi-libc, and wasi-sdk, and so on) and made some progress but there's nothing notable other than just having everything plumbed together to iterate on p3 libc support. I was hoping to do more of the work before ever mentioning it, but I want to make sure to reach out to see if what I'm doing fits into the plans for p3. Right now I've been working on wit-bindgen's c bindings.
If there's any interest at all in what I've done I'd be glad to push my work and we can take a look, otherwise I'm perfectly content continuing individually. I'd also be glad to rework any previous work to align with upstream goals.
Amber (Mar 31 2025 at 16:58):My implementation is driven by the ultimate task of "port tokio (and its internal deps) to wasip3" (at least as a fork I can use myself). I felt like the tokio port for p2 using libc looked pretty reasonable, so that's the approach thats driving my p3 work.
Joel Dice (Mar 31 2025 at 16:59):That sounds awesome! @Alex Crichton and I both started sketching wit-bindgen C support for component model async but haven't had a chance to take it beyond a sketch. Also, @Pat Hickey has been thinking about updating wasi-libc's support for p2 by removing the dependency on the p1->p2 adapter, which would be a helpful step towards native p3 support, so you might want to coordinate your wasi-libc efforts with him.
Posting here is a great way to start a discussion. In addition, opening a draft PR for the wit-bindgen C work would be a great way to collaborate and avoid redundant effort.
Amber (Apr 01 2025 at 19:35):I'm interested in taking a look at the existing sketches, I did a really cursory look for where that'd be , found this: https://hackmd.io/@NXXwAQZbQ8CTpJXGoJcJ8w/SyIwhv9i6, which I suspect is a start but I'm getting the impression there's more to find. Are there any other places I should look for existing conceptualization / implementation on the wit-bindgen c support?
Alex Crichton (Apr 01 2025 at 20:05):Currently there's no async support in wit-bindgen c, and while I was going to start it a month or so ago I still haven't gotten around to doing so. You're welcome though to try to take this on and see where it goes! I'll caution you though in that there is not a stable foundation to build on at this time. For example there are no runtime tests in the wit-bindgen repository for async things nor is it easy to set them up. Additionally we're still figuring out idioms and general infrasturctural questions, for example wasi-libc and wasi-sdk haven't started to add a p3 target yet (much less rustc). Basically there's a lot up in the air, and I mostly want to make sure to set expectations
Joel Dice (Apr 01 2025 at 20:32):This is my very rough, incomplete sketch of C bindgen support from a while ago: https://github.com/dicej/wit-bindgen/tree/c-async
The basic idea was that, for each async-lowered import (named "foo", for example), we'd declare three functions: foo, foo_lift, and foo_free, plus one type: foo_result_t. foo would return a foo_result_t which is a newtype wrapper around a general-purpose async_result_t type that looks something like:
typedef struct {
uint32_t status_code;
uint32_t subtask_handle;
uint8_t *params;
uint8_t *results;
} async_result_t;
The foo_lift function could be called once the subtask has reached STATUS_RETURNED and take a foo_result_t * parameter, plus outpointer(s) for each lifted result, lifting from the lowered results in async_result_t::results into the outpointer(s). The caller is then responsible for disposing of the foo_result_t by passing it to foo_result_free.
Note that I hadn't even started thinking about how exports would work, but Alex recently did some brainstorming about that: https://github.com/WebAssembly/component-model/issues/485#issuecomment-2766981494
Amber (Apr 01 2025 at 20:34):For what it's worth regarding the challenges of building on the existing foundation, I have a forked rust that I added wasm32-wasip3 to and integrated to the point that I can consume the target and build a crate. I also have libc, wasi-sdk, and wasi-libc set up to build a p3 sdk sysroot along with the rest of the existing targets. Obviously there is no actual p3 implementation so there's no impact for that work, but I should be pretty well set up to iterate on some wit-bindgen work for p3. Obviously the part where my work became definitely blocked was when none of the in-progress branches with wit-bindgen changes had full implementations of the new codegen for the p3 ABI. I also am entirely willing to do some work that with requirements that change later on, so I'd love to see where I can take wit-bindgen c support with the planning available right now
Amber (Apr 01 2025 at 20:58):My understanding is that long term what I've said I have doesn't meet the higher level desires for what an implementation looks like since I figure anything short of a fully unit/integration tested implementation isn't what you're looking for. I like testing so I would be fine if I had to do any of that work.
Ultimately what I feel like my expectation is, is that anything I do related to this task in the rustc and libc realm is something I'm doing without any proper planning or coordination and would treat it as such. The wasi-sdk, wasi-libc, and wit-bindgen work is relevant enough to the current phase of the p3 timeline as I understand it and so I'd continue collaborating until any potential other work I did might fit into the plans.
Alex Crichton (Apr 01 2025 at 21:40):The root of many of these changes will definitely start with C bindings for p3/async things, so that's probably a good place to start. The main thing is that it'll be kind of hard to test and exercise that at this time
Last updated: Apr 09 2025 at 00:13 UTC