Folks that have active work streams, will you post a quick update?
cc @Victor Adossi @Roman Volosatovs @Joel Dice

Bailey Hayes (Jan 15 2025 at 16:32):

Jan 15, 2025

We decided to rev the since versions as 0.3.0 will make breaking changes to the 0.2.x series. Expect all 0.3.0-draft WIT's to align to this. Once @Roman Volosatovs PR's for filesystem and sockets merge, wasi-cli is the next target. I believe we're very close to having a draft for WASIP2 interfaces (http draft already exists but will be updated once deps land).

Once the above is complete, adding support for WASIP3 interfaces in wasmtime and JCO can begin

Bailey Hayes (Jan 15 2025 at 16:40):

Items Ready for Work

Joel Dice (Jan 15 2025 at 16:41):

Async/future/stream/error-context support has been merged into wasm-tools and wit-bindgen and is available in their latest releases. Still iterating on the Wasmtime PR, knocking out todo items one by one. Hoping to move that one to "ready-for-review" by the end of the month. Meanwhile, it is feature-complete (modulo the error-context work Victor is doing, which I'm reviewing now), so feel free to clone the branch, kick the tires, and start adding WASIp3 support to wasmtime-wasi and wasmtime-wasi-http.

Victor Adossi (Jan 15 2025 at 16:41):

CC @Calvin Prewitt who is doing the actual bulk of the work of jco host async imports

Roman Volosatovs (Jan 16 2025 at 14:50):

will work on removing wasi:io/error.error dep from wasi:http and after that start WASI implementation in Wasmtime

Dave Bakker (badeend) (Jan 16 2025 at 14:52):

Thanks. I've got a few remarks on the wasi-sockets part. Hope to get it written down soon

Pat Hickey (Jan 16 2025 at 16:05):

What’s the status of implementing P3 streams and futures in wasmtime::component? That’s a prerequisite to a wasi impl, correct?

Joel Dice (Jan 16 2025 at 16:14):

@Pat Hickey see my update above; that's feature-complete and has decent test coverage. Working to get that PR in a reviewable state (hopefully in the next week or two), but meanwhile you can use my PR branch.

Pat Hickey (Jan 16 2025 at 16:28):

Thanks. I will take a look. I’ve been factoring out wasi-io from wasmtime-wasi so that at least that much can be built nostd, idk how that will intersect with these new streams and futures but hopefully they can plug together

Roman Volosatovs (Jan 17 2025 at 11:59):

Roman Volosatovs (Jan 17 2025 at 12:01):

Roman Volosatovs (Jan 17 2025 at 12:50):

Roman Volosatovs (Jan 21 2025 at 15:05):

Roman Volosatovs (Jan 21 2025 at 16:47):

btw, I've noticed that wit-bindgen-rt dependency, which appears to be used by async is missing out-of-the-box.
I believe deps are normally reexported by wit-bindgen, but in this case it appears that macro attempts to import from ::wit-bindgen-rt
cc @Joel Dice idk, if that's a known/fixed issue or do you want me to take a look?

Roman Volosatovs (Jan 21 2025 at 16:59):

Roman Volosatovs (Jan 21 2025 at 17:35):

Joel Dice (Jan 21 2025 at 23:43):

FYI, I'm starting to work on wit-bindgen C support for async/streams/futures, which will unblock wasip3 support in wasi-libc and the toolchains which depend on it.

Roman Volosatovs (Jan 22 2025 at 13:31):

wasi:clocks@0.3.0 test fails for now, but looks like we're pretty close to getting this working end-to-end:

Roman Volosatovs (Jan 22 2025 at 18:44):

I noticed the same "current task missing" panic when attempting to run the same test with async_support(false), i.e. using sync host bindings. It makes sense, since in that case none of the async machinery seem to be used
What is the current thinking around that - are we planning to support wasip3 on hosts without async_support at all?

Joel Dice (Jan 22 2025 at 18:48):

@Alex Crichton and I discussed this a while ago. We don't think WASIp3 or the component model async ABI make sense to support in Wasmtime with async_support(false), and we're actually considering deprecating Wasmtime's component model sync APIs (i.e. making async_support(true) the default and, eventually, only option for running components).

Roman Volosatovs (Jan 22 2025 at 18:50):

That sounds good to me and simplifies this effort - I won't be adding the sync bindings to wasip3 interfaces at all then :)

Pat Hickey (Jan 22 2025 at 18:53):

thanks Joel, that sounds right - we'll have to see about deprecating the sync stuff for p2 we already provide (hacky as it is, it does actually meet some users needs) but I agree we shouldn't worry about sync interfaces to p3 or async CM

Juniper Tyree (Jan 23 2025 at 06:42):

Do I understand correctly that the plan is that the CM host must support async, but that all components can still be fully sync (if one wants that)? If wasmtime will always use async, it may be useful to support compiling with a very cheap async runtime so that e.g. embedded usecases don’t need to pull in a costly featureful runtime

Pat Hickey (Jan 23 2025 at 18:03):

Pat Hickey (Jan 23 2025 at 18:04):

the existing P2 wasmtime-wasi always runs inside tokio, with the sync bindings it just hides that tokio in the background.

Roman Volosatovs (Jan 30 2025 at 18:06):

@Pat Hickey @Joel Dice @Alex Crichton @Victor Adossi I've sent you all invites to a 30 min call tomorrow, please let me know if that time slot does not work for you.
If it does, then first item on the agenda would be discussing time slots and making this a regular meeting :)

Roman Volosatovs (Jan 30 2025 at 18:07):

Roman Volosatovs (Jan 30 2025 at 18:45):

just realized I scheduled the meeting for next week :thinking: , just rescheduled for tomorrow, also moved it to a bit later to accommodate for US West Coast

Alex Crichton (Jan 30 2025 at 21:51):

Alex Crichton (Jan 31 2025 at 18:35):

joel/I won't be around next monday but don't let my absence block y'all the monday after that from meeting

Alex Crichton (Jan 31 2025 at 18:37):

Alex Crichton (Jan 31 2025 at 18:38):

I avoided a literal fork b/c i don't think github lets you fork a repo within the same org

Alex Crichton (Jan 31 2025 at 18:38):

Roman Volosatovs (Feb 01 2025 at 09:13):

Small follow-up to the discussion from yesterday, just for the sake of completeness - without any changes to the wasmtime bindgen, we should be able to use dynamic dispatch to avoid the complex state machines in implementations. I haven't tested it, but I don't see why returning a Box<dyn FnOnce(..)> wouldn't work.

It's essentially the same thing we've been doing for a long time with async_trait, but it does seem as a bit of a setback, since we'd not be able to "just" use Rust async. It also seems non-obvious for embedders, especially those not completely familiar with dynamic dispatch/async (e.g. explicit Box<dyn ..> bounds would likely be required to avoid compiler errors)

Just throwing it out there as a potential solution, I believe having "true" Rust async trait support would be a lot nicer/better

Joel Dice (Feb 02 2025 at 22:26):

Can you clarify how returning a Box<dyn ...> would help? I'm not seeing what part of the problem it solves.

Joel Dice (Feb 02 2025 at 22:28):

FWIW, I just sketched out a potential API based on a thread-local variable which is only set to a valid value when Wasmtime is polling futures created by functions registered using LinkerInstance::func_wrap_concurrent: https://gist.github.com/dicej/21519f9cf2e4d57a3316ea0b2167d281

Roman Volosatovs (Feb 03 2025 at 14:06):

diff --git a/crates/wasi/src/p3/sockets/host/types/tcp.rs b/crates/wasi/src/p3/sockets/host/types/tcp.rs
index e2a45eb6c..c5f3cbb7f 100644
--- a/crates/wasi/src/p3/sockets/host/types/tcp.rs
+++ b/crates/wasi/src/p3/sockets/host/types/tcp.rs
@@ -45,64 +45,65 @@ where
         let ctx = store.data().sockets();
         let allowed = ctx.allowed_network_uses.tcp;
         let socket_addr_check = ctx.socket_addr_check.clone();
-        let sock = store
+        let tcp_socket = match store
             .data_mut()
             .table()
             .get_mut(&mut socket)
             .context("failed to get socket resource from table")
-            .map(|socket| {
-                let tcp_state = mem::replace(&mut socket.tcp_state, TcpState::BindStarted);
-                if let TcpState::Default(sock) = tcp_state {
-                    Some((sock, socket.family))
-                } else {
-                    socket.tcp_state = tcp_state;
-                    None
-                }
+        {
+            Ok(sock) => sock,
+            Err(err) => {
+                return Box::pin(async move {
+                    for_any(Box::new(for_any(move |_| Err(err)))) as Box<dyn FnOnce(_) -> _>
+                }) as Pin<Box<dyn Future<Output = _>>>
+            }
+        };
+        let tcp_state = mem::replace(&mut tcp_socket.tcp_state, TcpState::BindStarted);
+        let sock = if let TcpState::Default(sock) = tcp_state {
+            sock
+        } else {
+            tcp_socket.tcp_state = tcp_state;
+            return Box::pin(async {
+                for_any(
+                    Box::new(move |_| Ok(Err(ErrorCode::InvalidState))) as Box<dyn FnOnce(_) -> _>
+                )
             });
+        };
         let local_address = SocketAddr::from(local_address);
-        async move {
-            let res = match sock {
-                Ok(sock)
-                    if !allowed
-                        || !socket_addr_check(local_address, SocketAddrUse::TcpBind).await =>
-                {
-                    if let Some((sock, ..)) = sock {
-                        Ok(Ok((sock, Err(ErrorCode::AccessDenied))))
-                    } else {
-                        Ok(Err(ErrorCode::AccessDenied))
-                    }
-                }
-                Ok(Some((sock, family))) => {
-                    let res = bind(&sock, local_address, family);
-                    Ok(Ok((sock, res)))
-                }
-                Ok(None) => Ok(Err(ErrorCode::InvalidState)),
-                Err(err) => Err(err),
-            };
-            for_any(move |mut store: StoreContextMut<'_, Self::TcpSocketData>| {
-                let sock = res?;
-                let socket = store
+        Box::pin(async move {
+            if !allowed || !socket_addr_check(local_address, SocketAddrUse::TcpBind).await {
+                return Box::new(move |mut store: StoreContextMut<'_, Self::TcpSocketData>| {
+                    let tcp_socket = store
+                        .data_mut()
+                        .table()
+                        .get_mut(&mut socket)
+                        .context("failed to get socket resource from table")?;
+                    tcp_socket.tcp_state = TcpState::Default(sock);
+                    Ok(Err(ErrorCode::AccessDenied))
+                }) as Box<dyn FnOnce(_) -> _>;
+            }
+            Box::new(move |mut store: StoreContextMut<'_, Self::TcpSocketData>| {
+                let tcp_socket = store
                     .data_mut()
                     .table()
                     .get_mut(&mut socket)
                     .context("failed to get socket resource from table")?;
-                let (sock, res) = match sock {
-                    Ok(sock) => sock,
-                    Err(err) => return Ok(Err(err)),
-                };
                 ensure!(
-                    matches!(socket.tcp_state, TcpState::BindStarted),
+                    matches!(tcp_socket.tcp_state, TcpState::BindStarted),
                     "corrupted socket state"
                 );
-                if let Err(err) = res {
-                    socket.tcp_state = TcpState::Default(sock);
-                    Ok(Err(err))
-                } else {
-                    socket.tcp_state = TcpState::Bound(sock);
-                    Ok(Ok(()))
+                match bind(&sock, local_address, tcp_socket.family) {
+                    Ok(()) => {
+                        tcp_socket.tcp_state = TcpState::Bound(sock);
+                        Ok(Ok(()))
+                    }
+                    Err(err) => {
+                        tcp_socket.tcp_state = TcpState::Default(sock);
+                        Ok(Err(err))
+                    }
                 }
             })
-        }
+        })
     }

     fn connect(

something roughly like this. I did not play the lifetime bingo to solve the "one type is more general than the other" and "implementation of FnOnce is not general enough", but that's a potential workaround (which, it seems, would require even more helpers akin to for_any). I'm not sure if it's more ergonomic or clear.

Joel Dice (Feb 04 2025 at 13:59):

FYI, I just pushed my async branch to the main branch of the wasip3-prototyping repo. I won't rebase it anymore after that; we can merge from upstream main as necessary, which should be less disruptive than rebasing.

Pat Hickey (Feb 05 2025 at 17:35):

I missed wherever this came up on github - whats the reasoning behind dropping the -draft suffix on wasi 0.3 wit packages versions?

Roman Volosatovs (Feb 05 2025 at 18:14):

Roman Volosatovs (Feb 05 2025 at 18:15):

Pat Hickey (Feb 05 2025 at 18:40):

Roman Volosatovs (Feb 05 2025 at 18:56):

I think so, however is there a particular reason we'd want the -draft suffix?
Since the interfaces are in a separate (draft) directory within proposal repositories anyway, the fact that those interfaces are "draft" should be clear and not introducing the suffix seem to minimize the churn

Bailey Hayes (Feb 05 2025 at 19:14):

It's a precedent we set with wasip2. We don't want anyone to accidentally think wasi 0.3.0 is ready. We're also expecting to make a series of updates as these are unlikely to be the final versions of the interfaces. -draft makes that easier.

Pat Hickey (Feb 05 2025 at 22:01):

Victor Adossi (Feb 10 2025 at 17:14):

It looks like a signature (body.finish) needs to change given that internally it produces an error-context. There are many options for how to fix it, but it would be great to get that fix in upstream on the 0.3.0-draft

Roman Volosatovs (Feb 10 2025 at 17:30):

A quick summary of the status meeting earlier today, please let me know if I missed something:

Joel Dice (Feb 10 2025 at 20:02):

Roman Volosatovs (Feb 11 2025 at 10:58):

Awesome, thanks @Joel Dice ! Just tested it and can confirm that it fixed the issue I've encountered :)

Joel Dice (Feb 12 2025 at 01:33):

Roman Volosatovs (Feb 12 2025 at 15:40):

Roman Volosatovs (Feb 12 2025 at 19:12):

Joel Dice (Feb 12 2025 at 22:38):

Roman Volosatovs (Feb 13 2025 at 16:42):

Thanks @Joel Dice !
Working on listen I'm getting a sefault with this API and I've also ran into the failed to get promise due to cannot remove owned resource while borrowed again, looks like there's indeed a bug, which is likely similar to what happened with borrows.

What's the most efficient way to proceed here?
Should I file issues with reproduction steps?
Would it help to get on a call and pair?

Joel Dice (Feb 13 2025 at 16:46):

Filing issues would be ideal. They don't need detailed descriptions -- just brief descriptions of each issue with steps to repro.

Joel Dice (Feb 13 2025 at 16:49):

BTW, I've been wondering how listen: func() -> result<stream<tcp-socket>, error-code> is supposed to work given that the tcp-socketborrow only lasts until listen returns, i.e. the callee no longer has access to it after returning, so it can't use it in the spawned task. Curious if @Luke Wagner has guidance on this.

Roman Volosatovs (Feb 13 2025 at 17:05):

Roman Volosatovs (Feb 13 2025 at 17:16):

Joel Dice (Feb 13 2025 at 17:49):

Roman and I discussed this in today's Wasmtime meeting and he clarified that the host implementation of listen does not attempt to use the borrowed resource as such after the function returns -- instead it clones the backing implementation and uses that, which makes sense. And I guess a component-implemented version could do the same thing by making the exported tcp-socketresource implementation contain a cloneable and interior-ly mutable state which may be cloned for post-return use.

Roman Volosatovs (Feb 13 2025 at 17:54):

Joel Dice (Feb 13 2025 at 18:30):

@Roman Volosatovs The segfault you found is the same as the one I discovered last week in the context of epoch interruption (although it turns out it can happen even with epoch interruption disabled) and am in the process of addressing. Meanwhile, this tiny PR makes it panic instead of segfault.

Roman Volosatovs (Feb 13 2025 at 18:48):

Awesome, thanks for looking into it. Can confirm that it does not segfault anymore! :)

Joel Dice (Feb 13 2025 at 22:38):

Victor Adossi (Feb 14 2025 at 03:03):

Do we want to get CI running on the prototyping repo? I must have missed the how/when/why of when it was disabled, but having some tests run at PR time is likely better than none.

It's not a showstopper as I think a forking workflow would allow all the changes anyone wanted, but just bringing it up here for discussion.

Joel Dice (Feb 14 2025 at 04:16):

Joel Dice (Feb 14 2025 at 21:54):

@Roman Volosatovs This PR addresses #9. BTW, I merged my other outstanding PRs (despite not yet being approved) because juggling 4 different branches was irritating me. I'd also like to merge yours as soon as it's somewhat stable (#[ignoreing tests as necessary) so we don't need to jump back and forth so much.

Joel Dice (Feb 14 2025 at 21:57):

With that PR, the tests that were failing due to #9 no longer panic, but they hang indefinitely, consuming no CPU. Not sure if that's a bug in the tests or in Wasmtime; I haven't had a chance to study them yet.

Joel Dice (Feb 14 2025 at 22:00):

I general, I think we can be pretty aggressive about merging PRs for now and avoid long-lived branches. We're going to split it all up again for upstreaming anyway; for now let's keep things simple. Enabling CI as Victor suggested will help avoid stepping on each others' toes.

Roman Volosatovs (Feb 19 2025 at 13:01):

Sounds good, I've rebased https://github.com/bytecodealliance/wasip3-prototyping/pull/1 on latest main and marked it ready for review.
Unfortunately, I was not able to enable all TCP tests yet, as it seems I'm hitting a deadlock with stream I/O, the host never receives the data that the guest sends. I'll file an issue later today

Joel Dice (Feb 19 2025 at 14:23):

Yeah, that deadlock sounds like the hang I saw last week. I can look into that today. If you can minimize the test case that reproduces it at all, that would definitely help.

Roman Volosatovs (Feb 19 2025 at 15:26):

Neither of these calls ever resolve, as if the futures are not polled
I'm using the Promise::into_future in the host, which seems to be the right thing to do according to the docs, I have not tried it with Promise::get

Joel Dice (Feb 19 2025 at 15:27):

Yeah, Promise::into_future is the only one that makes sense in this context. I'll take a look.

Joel Dice (Feb 19 2025 at 18:40):

Based on println debugging the guest is not even reaching the line you linked to. Since the guest has lowered thetcp-socket.send import synchronously, and the implementation is trying to read the entire stream<u8> before returning, there's no way it will ever return; the guest is blocked on that call and will never write anything to the stream.

I think you'll want to lower the tcp-socket.send import asynchronously and await it concurrently with a future that feeds the write end of the stream (e.g. using join or FuturesUnordered). Happy to pair on this when you're available.

Roman Volosatovs (Feb 19 2025 at 19:59):

Roman Volosatovs (Feb 19 2025 at 20:53):

had a few minutes to try it out https://github.com/bytecodealliance/wasip3-prototyping/pull/17, will need to figure out a way to properly adapt the wasip2 test expectations regarding the behavior, but looks like it works. tcp_streams still hangs, but that's likely due to some write handle not being dropped. Will continue tomorrow.
Thanks for taking a look, looks like we'll be able to have the complete TCP test suite working tomorrow

Roman Volosatovs (Feb 20 2025 at 11:15):

Interesting, looks like I found another issue - the BackgroundTask is not awoken by the executor after returning Poll::Pending.
I think it would be beneficial to pair later today!

Roman Volosatovs (Feb 20 2025 at 11:18):

Roman Volosatovs (Feb 20 2025 at 11:22):

specifically, this future never gets polled again after returning Poll::Pending, even though oneshot::Receiver poll should have registered the wakup event once the oneshot::Sender is dropped (I have verified that it indeed gets dropped) https://docs.rs/tokio/latest/tokio/sync/oneshot/struct.Receiver.html

Joel Dice (Feb 20 2025 at 14:44):

@Roman Volosatovs dummy_waker is only used in first_poll and poll_and_block, and those are only used for guest->host calls in host.rs, meaning dummy_waker should never be used for spawned tasks. Instead, spawned tasks are pushed directly to ConcurentState::futures, and that is always polled with the Context received from the embedder's executor (i.e. Tokio in this case).

My guess is that we're not polling ConcurrentState::futures between when spawn is called and when we suspend the fiber and return control to the executor, i.e. the spawned future is not being polled at all. Or have you already verified that it's being polled at least once?

Roman Volosatovs (Feb 20 2025 at 14:59):

It gets polled once for sure. I'll be available in a few minutes, we could jump on a call if you're free

Roman Volosatovs (Feb 20 2025 at 15:06):

Joel Dice (Feb 20 2025 at 15:46):

Ok, after looking at the code, I think you're right that the issue is related to the guest synchronously dropping the listening tcp socket, which in the host drops the oneshot::Sender, but the guest code keeps running after the drop call returns, before the host has a chance to poll ConcurrentState::futures again.

Joel Dice (Feb 20 2025 at 15:47):

So we get the trap because the guest tries to bind again before the old socket has really stopped listening.

Joel Dice (Feb 20 2025 at 15:48):

I'm wondering if there's a way we can make HostTcpSocket::drop finish everything it needs to do (including waiting for the spawned future to complete) before returning.

Joel Dice (Feb 20 2025 at 15:50):

It's like the spawned future needs to send a confirmation back to HostTcpSocket::drop indicating it's done.

Roman Volosatovs (Feb 20 2025 at 15:50):

For my understanding then, are you saying the observed behavior is a race condition effectively?

Roman Volosatovs (Feb 20 2025 at 15:51):

Would the future eventually get polled on it's own or it does require something to trigger the poll?

Joel Dice (Feb 20 2025 at 15:51):

yes, I think the future would be polled if the guest were to yield between the drop and the bind

Roman Volosatovs (Feb 20 2025 at 15:52):

Joel Dice (Feb 20 2025 at 15:52):

or if (like I was saying), the host drop implementation were to wait for confirmation before returning

Joel Dice (Feb 20 2025 at 15:52):

Roman Volosatovs (Feb 20 2025 at 15:52):

Roman Volosatovs (Feb 20 2025 at 16:10):

actually, following-up to our discussion just now, I might try taking the task out from the drop directly, by wrapping the ListenTask itself

It does seem like a generally useful pattern, but I'm not actually sure if the abort handle should be responsibility of the runtime if we can figure that out by wrapping the task directly

Joel Dice (Feb 20 2025 at 16:11):

Roman Volosatovs (Feb 20 2025 at 16:12):

Roman Volosatovs (Feb 20 2025 at 16:37):

just as a very quick PoC, since I did not really find a nice way to close the listener yet, this seems to have fixed the issue.

I tried also wrapping the listener in an Option<std::sync::Mutex<TcpListener>>, but that got pretty awkward pretty quick although it potentially can work as well

Joel Dice (Feb 20 2025 at 16:38):

Yeah, I figured we'd need to use a Mutex somewhere given that the futures need to be Send + Sync

Roman Volosatovs (Feb 20 2025 at 16:39):

ah, actually, we could also use tokio::spawn directly and communicate with the BackgroundTask via a channel

Roman Volosatovs (Feb 20 2025 at 16:39):

Joel Dice (Feb 20 2025 at 16:40):

Roman Volosatovs (Feb 20 2025 at 17:07):

Joel Dice (Feb 20 2025 at 17:07):

Roman Volosatovs (Feb 20 2025 at 17:08):

Ralph (Feb 20 2025 at 17:31):

Roman Volosatovs (Feb 20 2025 at 18:22):

Joel Dice (Feb 20 2025 at 18:25):

Yikes, that drop implementation is complicated. This should make it a lot simpler:

Joel Dice (Feb 20 2025 at 18:25):

Joel Dice (Feb 20 2025 at 18:42):

Actually, the SpawnHandle/AbortOnDropHandle stuff is a bit trickier than I realized. I need to not just clear the Option but also wake the waker (i.e. the FuturesUnordered waker, in this case) so it knows to poll the wrapper future one last time and remove it from the set. Otherwise the wrapper future will be stuck in the FuturesUnordered forever.

Joel Dice (Feb 20 2025 at 18:43):

Roman Volosatovs (Feb 21 2025 at 12:43):

Ralph (Feb 21 2025 at 13:05):

Roman Volosatovs (Feb 21 2025 at 15:34):

Roman Volosatovs (Feb 21 2025 at 15:47):

Joel Dice (Feb 21 2025 at 15:54):

Roman Volosatovs (Feb 21 2025 at 15:55):

Joel Dice (Feb 21 2025 at 15:55):

Roman Volosatovs (Feb 21 2025 at 15:59):

pushed. just a heads-up, I'm noticing some flakiness in tcp_connect test, let's see if switching to the new spawn functionality fixes that. Otherwise, we can ignore it for now

Joel Dice (Feb 21 2025 at 16:01):

FYI, in the past when I've seen non-deterministic test behavior, I've been able to make it more consistent by adding/removing/adjusting sleep calls in host functions (e.g. artificially delaying tcp socket operations), so if we still see issues even with the new spawn feature, that might help with debugging.

Roman Volosatovs (Feb 21 2025 at 16:10):

I cancelled the CI run, if I'll manage to fix it, I'll push a fix within next 1.5h, otherwise I'll push an ignore for the flaky ones

Roman Volosatovs (Feb 24 2025 at 12:01):

@Joel Dice the fix for the race condition we discovered was fairly trivial https://github.com/bytecodealliance/wasip3-prototyping/pull/23
Note, that I cannot actually use the abort handle machinery out-of-the-box just yet due to the need of explicitly closing the stream write handle. Let's chat about it later today at the status update!

Victor Adossi (Feb 24 2025 at 17:19):

After talking with Joel at the P3 sync, we want to have body.finish not async (since it doesn't have to be, it's simply ferrying along the trailers), but right now creating a new future requires access to the store which currently is only doable from async functions.

This somewhat inconvenient, but brought up the idea that the lack of trailers and trailers that are present but empty are different -- which means option<future<trailers>> might be a reasonable thing to put on the table. Right now, to make future<trailers> work, if there are no trailers, we create a new future to essentially and make sure to write nothing.

I think you were against option<future<trailers>>, am I remembering correctly?

Joel Dice (Feb 24 2025 at 17:46):

To elaborate on what Victor said above: there's currently a limitation in wasmtime-wit-bindgen's Component Model Async support such that sync functions can't create streams or futures, but that's a temporary limitation we plan to address soon, so no need to design around it.

Pat Hickey (Feb 24 2025 at 18:49):

Victor Adossi (Feb 24 2025 at 19:56):

Thanks! Just to make sure I fully understand -- are you going for creating the future here (no option, i.e. returning future<trailers> no matter what) or returning an option<future<trailers>>?

Roman Volosatovs (Feb 25 2025 at 10:41):

following the discussion from yesterday, I've replaced the Tokio task/channel magic by AbortOnDropHandle machinery in https://github.com/bytecodealliance/wasip3-prototyping/pull/32, which does not rely on multi-threading anymore.
I think we need to talk a bit more about send and connect.
cc @Alex Crichton @Joel Dice

Roman Volosatovs (Feb 25 2025 at 18:05):

UDP implementation and tests: https://github.com/bytecodealliance/wasip3-prototyping/pull/33 - with this, we have latest wasip3 wasi:sockets draft fully implemented and tested using adapted wasip2 test suite. Will be starting with wasi:filesystem tomorrow.

Joel Dice (Feb 25 2025 at 18:12):

I got sidetracked yesterday fixing the soundness issue Alex raised in wasmtime-wit-bindgen's concurrent_imports option, as well as restoring support for &mut T forwarding impls so we can generate add_to_linker functions again. The good news is I got it working (should have a PR up today). The bad news is I didn't work on anything else. These are on my TODO list, though:

Joel Dice (Feb 25 2025 at 18:18):

@Roman Volosatovs when you switched to AbortOnDropHandle, how did you handle closing the StreamWriter? Or is that still a TODO blocked on the "auto-closing {Stream|Future}{Writer|Reader} on drop" item I mentioned above?

Roman Volosatovs (Feb 25 2025 at 18:38):

I actually did not make any changes in that regard - there are two tasks, both spawned via the store. The tasks communicate over an mpsc.

The producer side deals with all the OS-level stuff, I/O etc. , e.g. it owns the file descriptor (e.g. TCP stream) and it does not use the Accessor at all.
The consumer side owns the StreamWriter and is responsible for closing it once mpsc is closed and/or an unrecoverable error is encountered.

The abort handle of the producer task is stored as part of the resource state and so it's dropped once resource is dropped, triggering, e.g. close of a TCP stream FD.
The consumer task will eventually(likely on next poll) find out that the producer is closed and close the StreamWriter

Joel Dice (Feb 25 2025 at 18:39):

Joel Dice (Feb 25 2025 at 23:15):

@Alex Crichton @Victor Adossi I've been thinking some more about how to support creating futures and streams in sync host functions, and the easiest thing for the time being is to just tell wasmtime-wit-bindgen to generate an async function if it needs to create a future or stream (even if it doesn't need to await) -- which is exactly what Victor's PR already does. The guest can call that synchronously and everything will work as it should.

Alex and I have ideas about making both the async and sync bindings more flexible and ergonomic in the future, but for the time being I think it's fine to tell the binding generator to generate an async function any time the implementation needs to await or create futures or streams.

Tomasz Andrzejak (Feb 26 2025 at 14:56):

Hello :wave: this is probably a silly question but could someone explain what's the reason for changing the cli/stdio interface from:

Joel Dice (Feb 26 2025 at 15:01):

In the component model, the stream type always represents the readable end of a stream; there's no equivalent to output-stream for the writable end; which is to say that the component which creates a stream using stream.new can only give away the readable end and keep the writable end for itself. So the only way to hook a stream up to stdout or stderr is to create that stream using stream.new, hold on to the writable end, and pass the readable end to e.g. setStdout.

Joel Dice (Feb 26 2025 at 16:21):

The setStdout/setStderr API does raise an interesting question, though: If I compose two components and they both call setStdout, will one overwrite the other? I.e. is only one of the components going to be able to write to stdout?

Joel Dice (Feb 26 2025 at 16:23):

I imagine the host could maintain some kind of magic per-component state so that they don't overwrite each other, but I'm not sure that would be virtualizable by a guest component.

Roman Volosatovs (Feb 26 2025 at 16:31):

I'll also address the listen/receive stream capturing the lifetime of the socket resource later. (on that note, lazy question: does Rust guest wit-bindgen actually support this correctly, or does a returned stream capture the lifetime of the resource borrow the method was called on, in other words, are returned streams/futures 'static?)

Joel Dice (Feb 26 2025 at 16:31):

Alex Crichton (Feb 26 2025 at 21:46):

Joel there's changes in wasm-tools now to update various intrinsics and line up with the spec, do you want to coordinate about landing this within wasmtime? I ask because jsturtevant is working on a bugfix at wasm-tools#2076 which will unblock wasi-tls landing (this is completely unrelated to async), but I bring this up as that'll require updating wasm-tools.

The literal update is pretty modest but I suspect the actual changes to trampolines/tests to be a bit more invasive. In particular core wasm signatures are changing and things like waitable sets now need to be both created and destroyed around usages too

Joel Dice (Feb 26 2025 at 21:47):

Getting that upstream sounds fine to me and won't disrupt the WASIp3 work until we try to merge it into the wasip3-prototyping repo, but we don't need to do that right away. So no need to delay the former, and I'm happy to help if anything comes up.

Alex Crichton (Feb 26 2025 at 21:48):

although same question, but this time from wit-bindgen -- should I be careful about updating there or "update at will"?

Joel Dice (Feb 26 2025 at 21:49):

I'd say update at will; we can delay updating the dep in the wasip3-prototyping repo as well.

Roman Volosatovs (Feb 27 2025 at 17:04):

Roman Volosatovs (Feb 27 2025 at 17:10):

Roman Volosatovs (Feb 27 2025 at 17:14):

Alex Crichton (Feb 27 2025 at 21:01):

question on CI: there's a copy of main.yml but trimmed down -- is this because when I originally made the repo I disabled main.yml (named "CI") and it was thought we needed to copy that to get something running?

Alex Crichton (Feb 27 2025 at 21:02):

Joel Dice (Feb 27 2025 at 21:02):

Probably. In any case we're using wasip3-prototyping.yml (which we copied and modified) for PRs

Alex Crichton (Feb 27 2025 at 21:02):

Alex Crichton (Feb 27 2025 at 21:03):

Joel Dice (Feb 27 2025 at 21:03):

Alex Crichton (Feb 27 2025 at 21:03):

Victor Adossi (Feb 27 2025 at 21:03):

That would be awesome -- I set up the copy there to mostly do the same thing as main but hopefully run slightly faster without tests that we wouldn't impact

Joel Dice (Feb 27 2025 at 21:03):

Alex Crichton (Feb 27 2025 at 21:03):

Joel Dice (Feb 27 2025 at 21:04):

Victor Adossi (Feb 27 2025 at 21:04):

Yep, and another job for async specifically, mostly for visibility, the original goal was to only run those but figured there could be downstream effects

Alex Crichton (Feb 27 2025 at 21:05):

ok I'll work to try to figure out what's going on and see if changes are necessary

Victor Adossi (Feb 27 2025 at 21:05):

the async tests are under misc I'm not sure if that's covered under test by default but entirely could be!

Victor Adossi (Feb 27 2025 at 21:05):

Yup happy with any changes there -- having merge queues and any tests that are necessary re-enabled would be nice

Joel Dice (Feb 27 2025 at 21:06):

To be clear, the extra job Victor added runs cargo test -p component-async-tests, but there are other async-related tests elsewhere (e.g. bindgen and WA(S)T tests)

Joel Dice (Feb 27 2025 at 21:07):

I would expect cargo test --all to run the component-async-tests, but maybe it wasn't for some reason?

Joel Dice (Feb 27 2025 at 21:07):

Victor Adossi (Feb 27 2025 at 21:11):

Ah it does by default, run-tests.sh uses --workspace, wasn't necessary for me to use -p component-async-tests by default, but did like having it broken out like fiber. Certainly happy with having it all get back to a state more similar to upstream

Alex Crichton (Feb 27 2025 at 21:34):

ok in the main merge I'm deleting wasip3-prototyping.yml, I disabled cargo vet for anything outside of bytecodealliance/wasmtime (I'll land that upstream) and I'll work through the remaining failures

I'll have a follow-up which splits out the component-async-tests package to its own CI bucket which should still run on PRs by default.

I'm also enabling the merge queue. For now it's set as "merge & commit" as the strategy, but I'm only going to leave that for this one PR. The merge strategy is defined at the repo level, not the PR level, so my plan is to change that to "squash & merge" like wasmtime has after this merge lands

Roman Volosatovs (Feb 27 2025 at 22:13):

Squash & merge would complicate the eventual upstream contribution - I've set the strategy to "rebase" to allow for cherry-picking commits later

If others prefer squashes - that's fine, but I'd like to be able to keep merging my WASI PRs with rebase

Alex Crichton (Feb 27 2025 at 22:14):

Alex Crichton (Feb 27 2025 at 22:15):

it'll mostly just be annoying that if a merge from upstream back to wasip3 happens we'll have to update merge queue settings around that

Roman Volosatovs (Feb 27 2025 at 22:29):

Giving it a bit more thought, I don't think I actually mind squash merges at this point, my upcoming PRs should be rather small/well-scoped, so rebase or squash should not really matter any more, the "incremental" commits I cared about are already in main

Alex Crichton (Feb 27 2025 at 22:32):

Roman Volosatovs (Feb 28 2025 at 10:40):

Roman Volosatovs (Feb 28 2025 at 12:59):

Alex Crichton (Feb 28 2025 at 15:33):

Roman Volosatovs (Feb 28 2025 at 15:34):

Joel Dice (Feb 28 2025 at 18:25):

Heads up that I had a flash of inspiration last night regarding improving the{Stream|Future}{Writer|Reader} host API ergonomics, and the implementation is looking good so far; aiming to have PR up by EOD. In short, you'll be able to read, write, and close either end of a stream or future without needing a StoreContextMut. Ideally you wouldn't need one for creating streams or futures either, but that's going to be more difficult to achieve, so I'm punting on that for now.

Joel Dice (Mar 01 2025 at 00:43):

Joel Dice (Mar 01 2025 at 00:44):

@Roman Volosatovs I haven't added a way to get a Future that resolves when the other end of a stream/future is closed yet, but I'm planning to do that Monday.

Roman Volosatovs (Mar 03 2025 at 08:35):

I'm traveling today, so won't be able to make it to the status update call. On my way I'll be working on porting the rest of the p2 tests and finishing up the wasi:cli.
@Joel Dice do I understand correctly that you already have wasip3 wasi:http implementation complete or should I work on that as well?

Roman Volosatovs (Mar 03 2025 at 11:28):

wasi:cli https://github.com/bytecodealliance/wasip3-prototyping/pull/47
assuming that wasi:http is already complete, all of WASIp3 is implemented in the prototyping repo.
I'll be focusing on testing, refactoring and bug fixes now. hopping on a plane soon

Joel Dice (Mar 03 2025 at 14:50):

All I've done for wasi:http is sketch an implementation for testing purposes, based on a now-out-of-date draft. @Victor Adossi has done some work to partially sync it with the latest draft, but not entirely.

In any case, that implementation was only ever meant for runtime testing and examples; it has a bunch of TODOs, and I haven't tried to get the existing wasmtime-wasi-http tests ported over. So if you have bandwidth to work on any of that, it would certainly be appreciated!

Roman Volosatovs (Mar 03 2025 at 14:58):

Alex Crichton (Mar 03 2025 at 15:27):

I'll also have to dip out a bit early from the sync to run an errand too, I've mostly been working on the low-level tooling of wasmparser/etc sync'ing that with the spec and then working my way up to wit-bindgen with the goal of getting a C generator in mind (but also understanding the Rust generator at the same time)

Roman Volosatovs (Mar 04 2025 at 15:51):

It appears that wasm32-wasip2 target is not currently supported by Rust wasip3 components, is that right?

when trying to build a component with cargo build --target wasm32-wasip2 --release on:

Joel Dice (Mar 04 2025 at 15:53):

Ah, yeah, I guess that makes sense given that wasm-component-ld is using an older version of wit-encoder. We'd need a build with an updated dep.

Roman Volosatovs (Mar 04 2025 at 15:54):

so for now we should build for wasm32-unknown-unknown and componentize manually then?

Joel Dice (Mar 04 2025 at 15:54):

Victor Adossi (Mar 04 2025 at 15:54):

Roman Volosatovs (Mar 04 2025 at 16:19):

Alex Crichton (Mar 05 2025 at 15:32):

as a heads up I'm going to start the process today of updating wasm-tools everywhere. Stuff's probably gonna be broken for awhile.

Joel Dice (Mar 05 2025 at 15:33):

Alex Crichton (Mar 05 2025 at 15:33):

Joel Dice (Mar 05 2025 at 17:23):

Joel Dice (Mar 06 2025 at 14:35):

@Alex Crichton I'll merge upstream Wasmtime into wasip3-prototyping unless you've already started that.

Joel Dice (Mar 06 2025 at 14:38):

After that, I'm planning to work on https://github.com/bytecodealliance/wasmtime/issues/10338 and then host support for waitable sets. @Alex Crichton are you planning to work on guest (i.e. wit-bindgen) support for waitable sets?

Alex Crichton (Mar 06 2025 at 14:40):

You might have to temporarily disable tests I don't think my wit bindgen tests are sufficient just yet

Roman Volosatovs (Mar 06 2025 at 19:15):

btw, I noticed that wit-bindgen in main appears to be broken, and I had to roll back to the last-known-good commit for testing this in my wasi fork. I'll file an issue later upstream, but for now it can be reproduced with https://github.com/rvolosatovs/wasi/tree/feat/p3 and using latest main of wit-bindgen. Just thought it's important to call it out

Joel Dice (Mar 06 2025 at 19:16):

Alex Crichton (Mar 06 2025 at 19:17):

Joel Dice (Mar 06 2025 at 19:17):

Alex Crichton (Mar 06 2025 at 19:17):

it wasn't caught on CI because it's only a problem when things are compiled to wasm which the codegen tests aren't

Joel Dice (Mar 06 2025 at 19:19):

I think for the time being we need to test async-related wit-bindgen changes manually against wasip3-prototyping to catch stuff like that. Not ideal (and maybe not practical when stuff is out of sync), but something to aim for, at least.

Joel Dice (Mar 06 2025 at 19:19):

wasip3-prototyping is the only place we have runtime tests involving guest bindings for now

Alex Crichton (Mar 06 2025 at 19:19):

Joel Dice (Mar 06 2025 at 19:23):

No worries; looking forward to having runtime tests in the wit-bindgen repo so we don't have to remember anymore.

Joel Dice (Mar 06 2025 at 19:27):

No surprise; wit-bindgen hasn't been updated to match the latest wit-encoder. @Alex Crichton if you haven't already started that, I can dive in.

Alex Crichton (Mar 06 2025 at 19:28):

this is also making me rethinking if we should organize things a bit different w.r.t wit-bindgen and wasip3-prototyping,b ut that's for the side

Joel Dice (Mar 06 2025 at 19:29):

Well you are faster than me at pretty much everything, so feel free to take it; I could work on the task.return options stuff while you do that.

Alex Crichton (Mar 06 2025 at 19:29):

Joel Dice (Mar 06 2025 at 19:30):

Joel Dice (Mar 06 2025 at 19:32):

Joel Dice (Mar 06 2025 at 19:33):

oops, just realized I left a [patch] in the Cargo.toml to point to a local wit-bindgen; I'll revert that part

Joel Dice (Mar 06 2025 at 19:33):

Alex Crichton (Mar 06 2025 at 19:33):

Alex Crichton (Mar 06 2025 at 19:56):

Joel Dice (Mar 06 2025 at 20:54):

@Alex Crichton can you confirm that I'm remembering this correctly: In order to make the runtime task.return validation a single comparison, we're going to intern the dfg::CanonicalOptions in ComponentTypesBuilder (call it e.g. CanonicalOptionsIndex), then pair that with the TypeTupleIndex we're already using to intern the component return type, producing a third interned thing (call it e.g. TaskReturnIndex) that represents the pair. Then at runtime, we compare the two TaskReturnIndexes and trap if they don't match. Does that sound right?

Alex Crichton (Mar 06 2025 at 21:12):

Eventually yeah, but for now it's probably easier to just shepherd along options individually and check then all

Joel Dice (Mar 06 2025 at 21:13):

Already started down the intern path :). Shouldn't be a lot of work; just wanted to make sure it wasn't the wrong approach.

Alex Crichton (Mar 06 2025 at 21:13):

Joel Dice (Mar 06 2025 at 21:14):

Alex Crichton (Mar 06 2025 at 21:14):

I also realize we need to confirm what function equality means in the spec because interning misses runtime reexpots

Alex Crichton (Mar 06 2025 at 21:14):

Alex Crichton (Mar 06 2025 at 21:15):

Joel Dice (Mar 06 2025 at 21:17):

ok, so "unusual" components might fail the the runtime test even though they're actually following the rules?

Joel Dice (Mar 06 2025 at 21:17):

Alex Crichton (Mar 06 2025 at 21:17):

Joel Dice (Mar 06 2025 at 21:20):

Would RuntimeMemoryIndex, RuntimeReallocIndex, etc. help at all with the false traps?

Alex Crichton (Mar 06 2025 at 21:21):

Alex Crichton (Mar 06 2025 at 21:22):

We basically treat core modules as black boxes right now and don't detect reexports

Joel Dice (Mar 06 2025 at 21:30):

Should I be doing the interning in ComponentTypesBuilder? It currently doesn't know anything about memories or reallocs; those appear to be interned in LinearizeDfg instead. Is it okay to intern a struct that has e.g. a RuntimeMemoryIndex field in a ComponentTypes{Builder}?

Alex Crichton (Mar 06 2025 at 21:30):

Alex Crichton (Mar 06 2025 at 22:48):

Joel Dice (Mar 06 2025 at 22:49):

Alex Crichton (Mar 06 2025 at 22:50):

tl;dr; the --dummy support didn't emit intrinsics for things like futures/streams/task.return/etc, meaning that was never exercised in fuzzing, and the buggy module originally in wasip3-prototyping was exercising this

Alex Crichton (Mar 06 2025 at 22:50):

so I first updated --dummy to import all async intrinsics, and now that's turning up at least one other independent bug in wit-component

Alex Crichton (Mar 06 2025 at 22:51):

Alex Crichton (Mar 06 2025 at 22:52):

this all has to do with type encoding and making sure things are encoded in the right spot, and that's all super subtle and I always forget about it and just hope the fuzzer finds things (which it is now)

Joel Dice (Mar 06 2025 at 22:54):

Yeah, I've been eager to start (and also dreading) fuzzing all the things; glad we're finally starting to do that.

Alex Crichton (Mar 06 2025 at 22:54):

oh this is the fuzzer already going in roundtrip_wit in wasm-tools, and it's been doing async things for awhile

Alex Crichton (Mar 06 2025 at 22:54):

Alex Crichton (Mar 06 2025 at 23:25):

ok 4 other bugs fixed and the fuzzer now reached the original one I started with, yay!

Joel Dice (Mar 06 2025 at 23:44):

I've done the task.return type/options interning we discussed. It compiles, at least. Will test once the merge is complete.

Alex Crichton (Mar 06 2025 at 23:48):

Alex Crichton (Mar 06 2025 at 23:49):

the next step is adding struct WaitableSet to async_support.rs. Not hard but the fuzzer is finding more bugs in the background, you want to take over updating wit-bindgen from here?

Joel Dice (Mar 06 2025 at 23:51):

Joel Dice (Mar 07 2025 at 00:32):

Alex Crichton (Mar 07 2025 at 00:33):

Alex Crichton (Mar 07 2025 at 00:34):

via cargo update -p wit-component and I think it should pick up a fix I just pushed

Alex Crichton (Mar 07 2025 at 00:34):

Joel Dice (Mar 07 2025 at 00:35):

Alex Crichton (Mar 07 2025 at 00:35):

Alex Crichton (Mar 07 2025 at 00:36):

Joel Dice (Mar 07 2025 at 00:37):

Alex Crichton (Mar 07 2025 at 00:39):

Joel Dice (Mar 07 2025 at 00:41):

Alex Crichton (Mar 07 2025 at 00:41):

Joel Dice (Mar 07 2025 at 00:45):

Alex Crichton (Mar 07 2025 at 00:45):

Joel Dice (Mar 07 2025 at 00:46):

Alex Crichton (Mar 07 2025 at 00:46):

Joel Dice (Mar 07 2025 at 00:50):

about half of the integration tests are passing; not bad. The rest are dying with cranelift signature mismatch errors; presumably something wrong with in compiler/component.rs

Joel Dice (Mar 07 2025 at 00:51):

Joel Dice (Mar 07 2025 at 16:23):

All the integration tests are now passing. Just some WAT tests failing now; should be easy to fix.

Joel Dice (Mar 07 2025 at 16:27):

@Alex Crichton How would you feel about merging https://github.com/dicej/wit-bindgen/commit/b518c80c3707e5df8e890acb0444cf9f2588a8fc (which hard-codes the waitable-set handle to zero, since Wasmtime is currently ignoring it) as a temporary measure just to get things working again? I'll follow that up with proper waitable-set PRs for both wit-bindgen and wasip3-prototyping, but I don't want to block getting the merge into main while I'm doing that.

Roman Volosatovs (Mar 07 2025 at 16:38):

has anyone seen it before? Any ideas what might be going wrong?
@Joel Dice happy to jump on a call to look at it together if you're available

Joel Dice (Mar 07 2025 at 16:42):

That means the guest has received a stream handle it thinks it already owns. Yeah, a call would be good.

Joel Dice (Mar 07 2025 at 16:43):

As usual, if you can provide a (somewhat) minimized test case that would be ideal.

Roman Volosatovs (Mar 07 2025 at 16:45):

Joel Dice (Mar 07 2025 at 16:45):

Roman Volosatovs (Mar 07 2025 at 16:45):

Alex Crichton (Mar 07 2025 at 17:05):

Alex Crichton (Mar 07 2025 at 17:06):

my hope is to soon start digging more into refactorings for the rust guest bindings with more test cases using wit-bindgen test

Joel Dice (Mar 07 2025 at 17:11):

BTW, I just chatted with Luke, pointing out that a realloc option for task.return doesn't make sense because it only needs to lift values. He's going to remove that from the spec, and we may need to tweak the validation rules in wasmparser to match.

Alex Crichton (Mar 07 2025 at 17:11):

Alex Crichton (Mar 07 2025 at 17:12):

Alex Crichton (Mar 07 2025 at 17:25):

Joel Dice (Mar 07 2025 at 17:35):

@Alex Crichton Roman can provide more detail, but the issue he ran into above is the one you pointed out last week: writing to a "local" stream, then giving the read end away before that write completes. He's going to work around it, but now we have a real-world example.

Joel Dice (Mar 07 2025 at 17:36):

I guess that should be easier to fix than the opposite case (e.g. writing to a "remote" stream and then receiving the read end before the write completes).

Alex Crichton (Mar 07 2025 at 17:38):

makes sense yeah, and once we have things lined up again I'll start working on tests and fixes for these issues

Joel Dice (Mar 07 2025 at 17:40):

Joel Dice (Mar 07 2025 at 18:00):

Joel Dice (Mar 07 2025 at 19:57):

Coming back to the task-return interning and runtime validation thing: I have all but two tests passing. The two failures appear to be invalid components generated by wit-encoder such that the async-lifted export has a memory option (and indeed should have one), but the corresponding task.return does not. My guess it's due to the return type not needing a memory but the parameter types needing one. Will debug.

Alex Crichton (Mar 07 2025 at 19:58):

basically a "match" saying that a non-present memory is ok to have when the original intrinsic had a memory

Alex Crichton (Mar 07 2025 at 19:59):

b/c task.return validation will already require memory if it's needed and otherwise let it lie if it's specified and not needed

Alex Crichton (Mar 07 2025 at 19:59):

Also, given Luke's response on the upstream issue, interning definitely won't work here

Alex Crichton (Mar 07 2025 at 20:00):

Joel Dice (Mar 07 2025 at 20:00):

Alex Crichton (Mar 07 2025 at 20:00):

we could technically intern type+string-encoding, but I don't think that's worth it, so yeah 3 compares

Joel Dice (Mar 07 2025 at 20:16):

just to clarify: if either or both the task.return or the lift specify a memory that's not needed, that's ok? I.e. Wasmtime will need to do its own check to see if the memory is really needed based on the return type and set them both to null e.g. during instantiation so that we don't get spurious comparison failures?

Alex Crichton (Mar 07 2025 at 20:17):

I think no, what I'd expect is that if they're specified they're asserted to be equal

Alex Crichton (Mar 07 2025 at 20:17):

Joel Dice (Mar 07 2025 at 20:18):

ok, so wit-encoder does need to be fixed given that it's generating a lift where it's specified and a corresponding task.return where it's not

Joel Dice (Mar 07 2025 at 20:19):

and it's not wasmparser's responsibility to check that, because it can't in general (hence the runtime check)

Alex Crichton (Mar 07 2025 at 20:20):

Alex Crichton (Mar 07 2025 at 20:21):

b/c the lift may need it for arguments but not for the results, so it's valid that lift has it but task.return doesn't

Alex Crichton (Mar 07 2025 at 20:21):

(and this is where we should update the spec where if task.return is missing it and lift has it then that's ok)

Joel Dice (Mar 07 2025 at 20:22):

ok, so then it's not just a simple comparison at runtime is it? One will be null and the other will be non-null, and yet it shouldn't trap because we're saying that's okay.

Alex Crichton (Mar 07 2025 at 20:22):

Alex Crichton (Mar 07 2025 at 20:23):

personally I wouldn't worry too much about the cost of these checks, a few conditionals compared to the boxing/copying at the moment is where we're at

Joel Dice (Mar 07 2025 at 20:23):

Joel Dice (Mar 07 2025 at 20:24):

so if the task.return memory is null and the lift memory is non-null, then we say that's okay because wasmparser would have rejected a task.return that was missing a memory but needed it, correct?

Alex Crichton (Mar 07 2025 at 20:25):

Joel Dice (Mar 07 2025 at 21:29):

@Alex Crichton is there a way I can pass a reference to a memory to a intrinsic from a fused adapter module such that the host receives a *mut VMMemoryDefinition?

Alex Crichton (Mar 07 2025 at 21:30):

no the host will receive Runtime...Index and translate that using *mut ComponentInstance to the definition

Joel Dice (Mar 07 2025 at 21:38):

Follow up question: If I have a Option<MemoryIndex> can I turn that into a Option<RuntimeMemoryIndex> somehow? Or is MemoryIndex what I actually want anyway?

Alex Crichton (Mar 07 2025 at 21:38):

no you want RuntimeMemoryIndex, and if you plumb everything through dfg/etc I'd expect that to pop out

Alex Crichton (Mar 07 2025 at 21:39):

Joel Dice (Mar 07 2025 at 21:39):

Alex Crichton (Mar 07 2025 at 21:39):

or well, at some layer you'll have like a CoreExport, and somewhere during linearization that ...

Alex Crichton (Mar 07 2025 at 21:39):

Alex Crichton (Mar 07 2025 at 21:40):

Roman Volosatovs (Mar 12 2025 at 16:39):

the EOF parsing the component issue I've mentioned in the call turned out to be wasm-tools version mismatch after all.

Victor Adossi (Mar 12 2025 at 16:43):

One thing I also ran into was multi memory being required now where it wasn't before. Not sure how new that is, but moving from one commit of wasip3-prototyping to another it changed

(i.e. Before, my jco branch was using WASM2 | COMPONENT_MODEL | COMPONENT_MODEL_ASYNC and I needed to add MULTI_MEMORY)

Alex Crichton (Mar 12 2025 at 17:01):

Victor Adossi (Mar 12 2025 at 17:03):

As far as the multi-memory thing goes that MIGHT be unrelated, so I wouldn't pay too much attention to it for now, still going through things on the jco side, there are still a few tests failing there.

Victor Adossi (Mar 12 2025 at 17:05):

unfortunately there's no green test run before the 227.1 update but maybe once the dust settles I'll go back and bisect to get at it properly -- will avoid squashing until then

Roman Volosatovs (Mar 12 2025 at 17:05):

I've briefly mentioned it during the call earlier today, but I'll update in the thread as well.
I've managed to make Rust https://github.com/launchbadge/sqlx crate run using wasi:sockets@0.3.0-draft, in particular I was able to make the Postgres todos example in the sqlx repo work with real Postgres instance running in a container.

This, of course, was not meant to be a production-ready implementation, but really just a validation, and it looks like we're in a pretty good state.

I've recorded a video, but I'll be happy to write down the step-by-step instructions for running this if anyone is interested (please ask if you'd like that!)
Screen Recording 2025-03-07 at 17.01.24.mov

Joel Dice (Mar 13 2025 at 20:21):

@Alex Crichton It turns out we can't postpone supporting context.{get|set} in wasm-tools, wit-bindgen, and wasmtime after all. That's now the only way to save the guest-side task state (i.e. wit-bindgen-rt's FutureState) when returning from an async-with-callback-lifted export. We used to return a pointer to that state so the host could pass it back to us when calling the callback, but now we have to return a CallbackCode ORed with a waitable-set, and since we're avoiding using multivalue, the only way to stash and retrieve our task-local state is with context.{get|set}.

Anyway, assuming you haven't started adding support for those intrinsics anywhere, I'm going to start adding them, since I'll be blocked otherwise.

Alex Crichton (Mar 13 2025 at 20:23):

Alex Crichton (Mar 17 2025 at 19:37):

Continuing our discussion today of close-with-error -- I opened https://github.com/WebAssembly/component-model/issues/472 on this topic since I think the current behavior (assuming I'm understanding everything right) is hazardous as trapping conditions depend on what other components are doing, when I'd prefer to have a trapping condition be a purely local decision within a component

Alex Crichton (Mar 17 2025 at 19:42):

along the lines of "maybe can change things?" I'm also curious in that issue if it's possible to in theory remove error-context altogether (or basically consider it a WIT extension)

Alex Crichton (Mar 17 2025 at 19:42):

but I know I'm missing context, so I'd appreciate it if folks could help fill in the gaps

Alex Crichton (Mar 18 2025 at 20:19):

Alex Crichton (Mar 18 2025 at 20:37):

another issue -- https://github.com/WebAssembly/component-model/issues/475 -- with a change to futures/streams where they're likely to be represented in the future with two handles, not just one, and how we're still not 100% certain how this would all work

Roman Volosatovs (Mar 19 2025 at 15:32):

Feel free to join, especially, if you're well familiar with HTTP libraries in various guest languages

Roman Volosatovs (Mar 19 2025 at 15:34):

apologies for the short notice, I've been hoping to sum this up and open for discussion earlier this week, but I've been out sick for last 2 days

Roman Volosatovs (Mar 19 2025 at 17:45):

@Till Schneidereit @Luke Wagner I've moved away from the auto-close semantics in wasi:http, proposed in https://github.com/WebAssembly/wasi-http/pull/162, instead throwing an error explicitly if live handles exist. Please take a look!

Roman Volosatovs (Mar 21 2025 at 15:26):

Luke Wagner (Mar 21 2025 at 16:21):

Joel Dice (Mar 21 2025 at 18:57):

FYI, I'm doing a pretty deep refactor of concurrent.rs and futures_and_streams.rs in wasip3-prototyping, having realized yesterday that most of the state I had put in Store actually belonged in ComponentInstance. I don't anticipate any major public API changes, so it shouldn't affect the wasmtime-wasi(-http) work, but please avoid making changes to the aforementioned files until my PR is merged (or at least chat with me first).

Roman Volosatovs (Mar 31 2025 at 15:29):

Victor Adossi (Mar 31 2025 at 16:28):

Hey all, rough notes from the status meeting are below (Hey @Joel Dice unfortunately I missed your update so please feel free to fill it in :bow:):

2025/03/31 P3 Sync Meeting Notes

Notes

Joel's Update

Missed this, Yosh had it though

Alex's update

Rewrote all the streams stuff in the guest, basically.
Going to get more review from joel on the stuff that changed
Planning to start sketching task cancellation this week
- Will also chat with Luke about this
Topic about moving stuff in wind

Victor's update

Not doing much here -- work on jco and componentize-js is moving forward, but leaving error-context as is
Looks like we're all on the same page now (including Luke) with regards to what will stay for P3
Need to add feature gate to wasmparser
- Similar to async stackful, etc
Alex clarified that Wit bindgen work for converting test does not contribute to P3

Yosh's update

- Going to be out next week for 2 weeks

Discussion: wit-bindgen releases

We release wit-bindgen
You can export with one version and import with another and things are fine, this is nice
We need the thing sending the callback and the thing receiving to agree, and this can basically lead to a segfault
- w/ different versions the issue is we're basically assuming versions of data passed around
Not sure how to fix
- Maybe ensure everything passes through wasi-libc?
Joel: Let's put ourselves in the position of lib maintainers (C#, python, etc)
- They probably don't want to deal with things that are statically linked in)
- We probably want to avoid writing more C code here?
- Alex: was mainly thinking about wit-bindgen in Rust, but yeah solving that generally would mean solving for wasi-libc
- Joel: We could have a .a file that would get used in multiple places?
Joel: we need an official way to say I have a resources, and I want you to give me a file descriptor for the given resource
- This allows systems like dotnet to have heterogeneous collection of pollables, and await them with a single cal
- We already know several parties want this kind of functionality
  - Including mio
  - Idea is we want arbitrary
- Is there overlap with what we want for supporting aysnc & what we used to want for pollables -- can we write some C code to support that?
- Alex: Yes, that's correct there is no rust code in wasi-libc (not even component-ld)
- Alex: Some misgivings about random thing turning into file descriptor
Joel: Right now dotnet is using private wasi-libc APIs to reosurce to file descriptor
- They don't want separate code-paths for doing things like concurrently waiting on HTTP request and socket operations together easily
- Solution we give them needs to be better than reaching behind the scenes and using these private APIs
- There is some buy-in from dave & dan Gohman
- Alex: This feels like it would have a lot of overhead, but for other languages to do something like that is fine
- Refocusing on where the code should go:
  - Alex: for the Waker issue, it should probably be a VTable
- We're getting to the point that there are 4 bytes in wasi-libc, and that is the VTable pointer
  - Joel: Task local context get/set?
  - Alex: nope, that would be reserved for runtime doing exports
  - during execution of task, there is a static 4 bytes pointing to the vtable, but imports cannot assume anything, only exports get to use it
  - your state
  - Joel: What about coordinating between multiple languages? Vision was to move just enough into wasi-libc and that being the nexus
    - Alex: Yeah we're aligned here, just stating it differently -- the primitive is:
      - I'm importing some functionality
      - I need to get awaited
      - Imports need to communicate with some random export
  - Joel: And multiple epxorts
    - I'm providing an export, w/ arbitrary wit-bindgen version
    - Before exiting, in order to return a code back to the host, I need to reach down to wasi-libc to figure out WHAT to return
    - Alex: Not quite, the language
      - says as an import, a backcchannel to say "I just made an async call and it returned blocked, I'm telling you that I'm waiting on something"
    - Joel: OK: another example -- I can create a waitable set, but knowing what waitable to put in is hard
      - Need to return wait w/ a full waitable set.
      - Alex: When export started, you register your callback for waitable set changes
- Victor: This feels like a protocol, do we need to forward-version it?
  - Alex: We can have an extensible VTable in C, so there's a way to put a version in front of the vtable
  - anyone can register a VTable with any version, and we check the versions first, use baseline + whatever else
  - We probably will need to bake in some constraints that everyone has to support the v1 version or something
- Victor: What about some accretion only API with opt-in breakage (if you use v3, no v2)?
  - Alex: There could be an issue where you use a v3 API but a lib you're using uses v2
  - We would have to wait for the whole world to change before we could update
- Alex: Will write up a header file and a doc to describe what's going on

Roman's update

Thanks Joel & Alex for bugfixes!
Most tests pass now, looks to be in pretty good shape, this week will continue working on this
Hopefully something for wasi:http tomorrow
One question for stream/future -- no sync implementations any more (write_one rather than send())
- Alex: the actual APIs are completely changing -- streams have nothing to do with Sync or Rust stream trait
- type signature is completely different now, mostly related to buffer management
- Core primitive of stream write is rather than give a buffer and you lose it, you give a buffer it does a single write and you get back what happens
- Joel: Some work coming down to rebase on as well

Discussion: coordination with context.{get,set}

Joel: Each epxort will do a context.{get,set} pointing to whatever it wants to for that task?
- Task a/b/c will store completely separate things, but because they're different tasks they won't overlap
- So we don't need any agreement on what gets stored via those intrinsics
- Alex: On the rust side want two values -- magic value and a pointer & remove both at the same time
  - Joel: only problem was that Luke thought slot 0 should be the stack pointer for when we have multiple stacks... Maybe 3 slots?
  - Alex: probably a great thing to write down then, maybe languages should only use one of them
  - Joel: Yes, IIRC slot 0 was probably supposed to be special
  - Alex: Yup, languages probably want to add some magic and then remove/re-add it as operations go

Alex Crichton (Mar 31 2025 at 16:34):

Joel Dice (Mar 31 2025 at 16:35):

Roman Volosatovs (Apr 01 2025 at 16:34):

Joel Dice (Apr 01 2025 at 16:35):

Alex Crichton (Apr 01 2025 at 16:36):

Roman Volosatovs (Apr 01 2025 at 16:36):

Alex Crichton (Apr 01 2025 at 16:36):

that's under the assumption the bug lies in the previous wit-bindgen code, which could also be wrong

Joel Dice (Apr 01 2025 at 16:37):

I think there are still places in the host code that are too restrictive; we'll see.

Joel Dice (Apr 01 2025 at 16:37):

I don't think #94 will make a difference (regarding the trap), but I could wrong.

Alex Crichton (Apr 01 2025 at 18:48):

Alex Crichton (Apr 01 2025 at 18:51):

looks like http_0_3_outbound_request_content_length.rs is failing because trailers fail to get sent (I guess something hung up unexpectedly?) and p3::wasi_http_proxy_tests is not finishing so seems like a deadlock of some kind

Roman Volosatovs (Apr 01 2025 at 19:18):

Thanks Alex! Both are actually expected for now. For content length one we can't directly translate that from wasip3 - we'll have to call handle to actually try and send a request/response, was just chatting about it with @Pat Hickey
For the incoming HTTP I'll still have to wire up the set of promises to drive guest tasks after return

Roman Volosatovs (Apr 03 2025 at 13:48):

Joel Dice (Apr 03 2025 at 13:50):

I was planning to add some unit tests this morning, but I can go ahead and merge it and add the tests in a separate PR.

Joel Dice (Apr 03 2025 at 13:52):

Also, I should probably add BytesBuffer::into_inner and VecBuffer::into_inner methods for retrieving the unwritten items if desired. Let me know if you need either of those; they're trivial to add.

Roman Volosatovs (Apr 03 2025 at 13:57):

I think incremental changes are good and since the WASI tests pass, that's good enough for me, so I'd say go ahead and merge

Joel Dice (Apr 03 2025 at 13:57):

Roman Volosatovs (Apr 03 2025 at 14:52):

Roman Volosatovs (Apr 03 2025 at 14:53):

To be more specific, I'd want to get the Bytes from BytesBuffer, but I'd expect to only get the filled part of it, not the whole underlying buffer

Joel Dice (Apr 03 2025 at 14:55):

The idea with BytesMutBuffer::into_inner is that you'd call it when you just want to reuse the BytesMut without caring which parts were written and which weren't. Whereas the Deref impl gives you just the parts which haven't been written yet.

Joel Dice (Apr 03 2025 at 14:55):

I could alternatively change BytesMutBuffer::into_inner into fn into_parts(self) -> (BytesMut, usize) if that would be useful.

Joel Dice (Apr 03 2025 at 14:56):

Joel Dice (Apr 03 2025 at 14:58):

With VecBuffer<T>, it will be a bit different since we need to account for non-Copy T, so VecBuffer::into_inner will actually need to do a memmove to shift the unwritten items to the start of the Vec before returning it.

Roman Volosatovs (Apr 03 2025 at 14:59):

Joel Dice (Apr 03 2025 at 15:00):

Sure. The main idea is that you might either only care about the unwritten parts or just want to clear reuse the whole buffer or both. As long as we support all those options, we should be good.

Roman Volosatovs (Apr 03 2025 at 15:01):

Roman Volosatovs (Apr 03 2025 at 15:04):

Joel Dice (Apr 03 2025 at 15:06):

Maybe I'm not quite understanding. If you start with a BytesMutBuffer with, say, 16 bytes, then you do a write, and the write delivers 7 bytes, then offset will be 7 and remaining(&self) will return 9, and (currently) into_inner will return BytesMut with all 16 bytes. So what's the purpose of your truncate call above? Do you want the result to have the first 7 bytes or the last 9 bytes?

Joel Dice (Apr 03 2025 at 15:07):

Regarding Cursor: I sort of assumed it only worked with Copy payloads, but maybe I was wrong. Let me take a closer look.

Joel Dice (Apr 03 2025 at 15:10):

I guess it doesn't matter, since Bytes is only about u8, so yes, I guess we could get rid of BytesMutBuffer and BytesBuffer in favor of Cursor<BytesMut> and Cursor<Bytes> respectively, but keep VecBuffer since it supports moving owned values, which Cursor doesn't AFAICT.

Roman Volosatovs (Apr 03 2025 at 15:10):

I was actually thinking about the other way round, so doing a read, I'm still getting familiar with this new API. What I need is a way to go from StreamReader<BytesBuffer> to Stream<Bytes>. It appears that naive BytesBuffer::into_inner might give more bytes than the guest might have written

Joel Dice (Apr 03 2025 at 15:12):

All BytesBuffer::into_inner would do is give you back the entire Bytes (i.e. including both the written and unwritten bytes), which is what Cursor<Bytes>::into_inner also does if I'm reading correctly.

Joel Dice (Apr 03 2025 at 15:14):

Joel Dice (Apr 03 2025 at 15:15):

Oh, hold on. If you have a StreamReader, then you don't need to mess with BytesBuffer at all. BytesBuffer is only for writing -- it doesn't make sense for (and indeed won't work with) StreamReader.

Joel Dice (Apr 03 2025 at 15:15):

Roman Volosatovs (Apr 03 2025 at 15:15):

Joel Dice (Apr 03 2025 at 15:16):

er, I guess I mean StreamReader<BytesMut> since there's no way to add items to a Bytes

Roman Volosatovs (Apr 03 2025 at 15:26):

If you have a moment, we could jump on a call and I could quickly show you the use case I'm working with

Joel Dice (Apr 03 2025 at 15:27):

Roman Volosatovs (Apr 03 2025 at 15:27):

Joel Dice (Apr 03 2025 at 16:43):

BTW, if all you're doing is calling Promise::into_future the then later converting that back to a Promise, you could avoid both steps and just leave it as a Promise.

Joel Dice (Apr 03 2025 at 16:44):

I'll start working on replacing Bytes{Mut}Buffer with Cursor<Bytes{Mut}> next

Roman Volosatovs (Apr 03 2025 at 17:02):

I'd prefer leaving it as Promise, but that would prevent me from polling it multiple times in the guest task, since I have to move it to call into_future
That's the reason I'm suggesting the poll(cx, store) method on Promise, actually

Roman Volosatovs (Apr 03 2025 at 17:08):

Joel Dice (Apr 03 2025 at 17:09):

I think promise.poll(cx, store) would be equivalent to doing pin!(promise.get(store)).poll(cx)

Roman Volosatovs (Apr 03 2025 at 17:10):

Joel Dice (Apr 03 2025 at 17:11):

I think it should be fine; let me know if you see anything weird.
Yes, should be cancel safe, although that partly depends on the underlying Future wrapped by the Promise. All the existing public APIs that return Promises wrap cancel-safe Futures AFAIK.

Roman Volosatovs (Apr 03 2025 at 17:23):

Roman Volosatovs (Apr 03 2025 at 17:24):

Joel Dice (Apr 03 2025 at 17:25):

I could also add a Promise::get_mut() -> Pin<&mut dyn Future ...> method (or something like that; not sure about the types exactly)

Joel Dice (Apr 03 2025 at 17:26):

Joel Dice (Apr 03 2025 at 17:27):

Joel Dice (Apr 03 2025 at 17:28):

and if it doesn't then something's very wrong, because the future should close over the store ref

Joel Dice (Apr 03 2025 at 17:29):

Roman Volosatovs (Apr 03 2025 at 17:31):

Joel Dice (Apr 03 2025 at 17:31):

Joel Dice (Apr 03 2025 at 17:36):

I just realized Instance::promise will redundantly Box::pin the future you give it if it's already a Pin<Box<dyn Future>>> -- I should add a promise_from_boxed that takes an already-boxed future.

Roman Volosatovs (Apr 03 2025 at 17:48):

Joel Dice (Apr 03 2025 at 17:50):

Do arbitrary futures implement that? I want to make sure you can do e.g. let p = instance.promise(store, async move { ... });

Joel Dice (Apr 03 2025 at 17:51):

Joel Dice (Apr 03 2025 at 17:52):

Alternatively, we could just make Instance::promise require already boxed futures and make the caller box if necessary.

Roman Volosatovs (Apr 03 2025 at 17:53):

Roman Volosatovs (Apr 03 2025 at 17:56):

Joel Dice (Apr 03 2025 at 17:57):

Roman Volosatovs (Apr 03 2025 at 17:58):

Joel Dice (Apr 03 2025 at 18:21):

Just pushed the Cursor PR; taking a break for lunch, but will take a look at #100 after that if @Alex Crichton hasn't already figured it out.

Roman Volosatovs (Apr 04 2025 at 10:45):

@Joel Dice if I were to construct a Promise using Instance::promise, am I right in assuming that I can use Promise::into_future inside the future I passed to Instance::promise? (since it's running inside a Promise)

Joel Dice (Apr 04 2025 at 12:01):

Yes, correct. I started adding more docs with examples yesterday. I'll push a PR with those today.

Roman Volosatovs (Apr 04 2025 at 13:09):

Roman Volosatovs (Apr 04 2025 at 15:19):

Roman Volosatovs (Apr 04 2025 at 15:54):

Joel Dice (Apr 04 2025 at 16:13):

Awesome! Yeah, it will be great to get that merged finally so we're not juggling branches a rebasing so much. I'll take a look today.

Roman Volosatovs (Apr 04 2025 at 18:41):

Joel Dice (Apr 04 2025 at 18:43):

I saw that, and I'm as mystified as you. @Alex Crichton have you seen anything like that before (i.e. assert_eq! failing for integer values but then printing an error message that they're the same)?

Alex Crichton (Apr 04 2025 at 18:44):

in theory also UB where the compare is optimized to always false for some UB reason but then the print actually shows they're equal

Alex Crichton (Apr 04 2025 at 18:45):

Joel Dice (Apr 04 2025 at 18:46):

@Roman Volosatovs have you tried running those tests locally with cargo test --release by any chance?

Roman Volosatovs (Apr 04 2025 at 18:48):

Roman Volosatovs (Apr 04 2025 at 18:50):

Roman Volosatovs (Apr 04 2025 at 18:51):

Roman Volosatovs (Apr 04 2025 at 18:52):

Feels like maybe the right thing to do is run these in qemu to see if it's riscv64 specific

Alex Crichton (Apr 04 2025 at 18:52):

Alex Crichton (Apr 04 2025 at 18:58):

Alex Crichton (Apr 04 2025 at 20:24):

I'm switching the p3-prototyping repo to use merge commits instead of squash, I think squashing is making merging with main worse

Roman Volosatovs (Apr 07 2025 at 12:35):

Joel Dice (Apr 07 2025 at 13:31):

Joel Dice (Apr 07 2025 at 14:58):

I just ran the tests on main using cargo test -p wasmtime-wasi-http --test all --target riscv64gc-unknown-linux-gnu --release with QEMU 9.1.2 after removing all the ignore attributes from the http_0_3_* tests and they all passed. Am I doing something wrong?

Alex Crichton (Apr 07 2025 at 14:59):

try this:

CARGO_INCREMENTAL=0 CARGO_PROFILE_DEV_DEBUG=0 CARGO_PROFILE_TEST_DEBUG=0 CARGO_PROFILE_DEV_OPT_LEVEL=2 WASMTIME_TEST_NO_HOG_MEMORY=1 cargo test -p wasmtime-wasi-http --test all --target riscv64gc-unknown-linux-gnu p3::outgoing::http_0_3_outbound_request_invalid_header

Joel Dice (Apr 07 2025 at 15:01):

Roman Volosatovs (Apr 07 2025 at 15:01):

just a small note that if you rebase on latest main, the test will be called p3::outgoing::p3_http_outbound_request_invalid_header

Victor Adossi (Apr 07 2025 at 16:32):

P3 sync meeting for 2025/04/07

Attendees

Name
Joel Dice
Roman Volosatovs
Victor Adossi
Alex Crichton

Notes

Roman's update

WASI HTTP PR is landed:
- https://github.com/bytecodealliance/wasip3-prototyping/pull/58
- Some loose ends, RISCV tests are still broken
Switching focuses to ensure that this can be upstreamed
- extracting common stuff, straightening out p2 and p3 modules
- goal is to extract a PR that could be merged upstream
Not going to touch I/O for now (as Joel works on promises & futures)
Going to show a little demo today
- (Roman did a demo of the p3 HTTP component working, and a comparison)
- perf degradation since of course p3 has to do more things
  - p2's does ~37k req/sec, p3 does ~25k req/sec

Joel's update

Unblocking Roman last week, ensuring you could retrieve buffers after incomplete write
Fixing bugs, did some debugging with Alex
- Hopefully fuzzing will help this in the future
Public API refactoring underway for futures/promises, already discussed w/ Roman & Alex last week

Alex's update

Chasing/fixing bugs
Want to get to a binary format that is stable
- Want to move this into nightly rust, wasi-sdk, wasm-component-ld
- want to hold off on this until cancellation is sketched out
Joel: So for now to build for P3, we build for P2, and we automatically get a wasm-component-ld w/ new-enough version that does P2 & new async?
- Alex: Yep
- Joel: Then eventually we will have a real p3 target once wasi-libc is updated, etc
Joel: Could we consider a stage at which p3 target in wasi-libc uses the p2 APIs and then adding native P3 support?
- Alex: Makes sense, but this is basically what the P2 target already is (better messaging might be important)
- Alex: We should be able to mostly hide this under the covers
Roman: Adapter for p2->p3?
- Alex: would like to avoid for sockets
- Alex: would rather maybe do it for files, but adapter is going to be painful to write and not very well exercised
  - Easier to change adapter, go to p3 then change sockets and go to p3.
- Joel: Probably worth updating/checking with Pat on this
  - Basically what we could do is have the p3 target use a mix of P2 and P3
Alex: the main problem is not many people want to write C

Sidetrack: being ready for wasi-libc changes/evolution

Joel: Talked to dave a bit about the TLS stuff,
Current pattern is a bit hard to do becasue wasi-libc only gets an fd to represent the connection, and trying to close it and move resource handles then give them back.
We don't want to bake "POSIX" into WASI-TLS, like other stacks are doing
WASI-libc may turn into more than a C library, w/ APIs that are wasi specific
- ex. what if we want to poll/select with a mix of sockets and HTTP requests -- we need a way to synthesize fds that wouldn't normally make sense in a libc context.
Alex: There aren't enough maintainers for wasi-libc
Joel: What about implementing the sockets in Rust, then had a way to plug that in?
- Generally the flow is:
  - Make me a synthetic, opaque file descriptor
  - When I call poll(), here's how you get waitables (no longer pollables)
  - We write the sockets impl in Rust, but somehow enable POSIX send()/recv()
- Alex: Yeah we probably should not put async support in POSIX poll
  - We basically should avoid trying to get this working except for previous code that needs it (and that doesn't exist)
- Joel: Yeah that solution may not work but this has come up in mio and stackless/etc in WASI p2
  - w/ the way dotnet & mio fork work is that it reaches into non-public APIs in wasi-libc to take an FD & get handles (input/output stream)
  - it does it's own poll loop (not POSIX poll -- direct wasi p2 poll), w/ related interest (resources, clocks, etc)
  - We want to move away from non-public APIs
  - How can dotnet do what it wants to do: (set of sockets, set of HTTP connections), wait on all of them
    - Alex: If people have existing code w/ this problem (on native), someone should have done the work to do that separately
    - If mio wants to do WASI specific stuff that should live at the
  - Joel: thinking of the dotnet stuff, we've got a great WASI-based impl at this point (already) -- is the suggestion that they need to decide they're going all-in on POSIX (& base on wasi-sockets) or go all-in on WASI HTTP (& do socket stuff without wasi-libc)? i.e. all in on native wasi or POSIX, but not mix?
    - Alex: Essentially yes, it's probably a bad idea to support a mix
    - The problem is that adding a VTable means we basically can't ever change it again
    - Roman: Would agree with Alex here -- only expect wasi-libc to not have anything POSIX does
    - Joel: reasonable, but the idea that an ecosystem should have to choose between sockets/libc versus using the new WASI stuff directly there should maybe be a middle ground.
      - Ideally: Don't use wasi poll/select, but being able to use a fd in your tree and be able to use it with wasi-libc
      - Alex: It's not that we shouldn't be able to do that, but the conversions should be very targeted -- we shouldn't promise that people can kind of sprinkle WASI and things will be fine. We intentionally can't compile existing software as-is because it's a new model.
      - If you call open in wasi-libc, you should be able to get access to the underlying resource
      - It may make sense to temporarily create a fd that is matched to the resource, not refer to a vtable that has all the expected sockets
      - Roman: If you're using TLS, that means you're already using WASI right?
        
        Joel: This was during some discussions with James, and the vision was establishing a connection and being able to take resources, then perform wasi-tls stuff, then give wasi-libc back a socket & handles, and wasi-libc can put that back in the pool and use it.
        
        Alex: Against this because no other libc does this
        
        Joel: SSL module would be bridging the gap between OpenSSL and wasi-libc to replicate experience
        
        Roman: Why not use wasi-sockets directly in the python module?
        
        Joel: two reasons:
        
        porting cpython to WASI is harder than before (new code path)
        
        3rd party software that is very POSIX-tied, they need to also start using WASI directly
        
        Alex: You can use POSIX sockets from wasi-libc
        
        Joel: Maybe the answer is doing half of the proposal,
        
        First half is taking a socket (from 3rd party lib? from wasi-sockets support?)
        
        Take ownership from wasi-libc
        
        Give back the application the SSL connection
        
        As long as the application has no way of asking wasi-libc about it then it's fine
        
        Joel: Big if is if there's somewhere where the file descriptor is still used
        
        Alex: Avoiding taking in POSIX stuff in the python ecosystem
        
        Victor: could we do something to build wasi-libc in a way that enables this easier use case
        
        Alex: Yeah but if you're writing
Victor: Why is wasi-libc not a Rust thing?
- Alex: Easiest option was Musl compiled to wasi
- Only I/O system layer is what we have to maintain -- very different from having to maintain 100% of the libc
Victor: Do people like Cmake??
- Alex: Yeah depends on who you ask
- Joel: For windows, good for cross-platform

Enabling component-async in engine

Roman: Had to enable async, but after doing that tests actually fail
- Compiled module does not have the compiled in feature
- Alex: this is probably a bug, we try to ensure that the settings @ compile time are the same at runtime, for feature enabling some things are stricter than none
  - Roman: So in principle we should be able to enable async support (by default, for example) and everything should still work
    - Joel,Alex: Yes
Roman: Should we have a p3
- Alex: so -S p3 and -W cm-async
- Joel: p3 implies async but not the other way?
  - Alex: Probably better to just tie them together, you could technically use p3 and do sync everything
- Wordy but has to be done
- Joel: P3 on the host side is going to use cm-async flags so

Increasing test coverage on wasi-p3

Roman: Want to increase test coverage, but need to use raw WASI
Alex: We should not test to the stdlib -- that testing should likely be done on the Rust side
Roman: Discussed with pat about the size of test-programs (size is growing)
- Alex: Specific concerns about the size?
  - Roman: Fine with it, if we're compiling everything into wasm32-unknown-unknown, then probably fine
  - Roman: Over 207 test programs now
- Alex: wit-bindgen test-suite has gone well, and it turns out trying to push it all into one suite doesn't work well
  - Most reasonable thing might be to try to make these all wasi:cli CLI tests, but it won't be easy
  - One host module, which is the CLI, and all the tests run the WASM?
  - Joel: Could use WAVE here?
Let's punt this for now

Joel Dice (Apr 07 2025 at 17:34):

For the record: the riscv64 failure appears to be a pre-existing Cranelift codegen bug; @Alex Crichton is going to investigate further.

Alex Crichton (Apr 07 2025 at 17:37):

Dave Bakker (badeend) (Apr 07 2025 at 20:20):

I wasn't present during this meeting, so I'll be extrapolating purely based on the notes. The following cherry picked items resonated with me:

I am not much a C developer either. I've only worked on wasi-libc during the initial implementation of wasi-sockets together with Joel, but I wouldn't describe my time working on wasi-libc as "fun". To the point that I dread working on it again, despite the socket work not being complete. :neutral: To make things worse, once shared-everything-threading becomes a thing, I suspect wasi-libc will start breaking left and right because I'm not confident at all that what I wrote is thread safe.

I realize there's a lot of value in continuing off the work provided by MUSL. So I wonder if there's another middle ground here where e.g. we keep using MUSL for pretty much everything, but write the POSIX<->WASI IO interop layer in a statically linked Rust library, similar to the p1-to-p2 adapter.

I worry this all-or-nothing approach will be a tough pill to swallow for language/framework authors. But I'm fine deferring this until real world users come knocking

Pat Hickey (Apr 07 2025 at 20:30):

std will probably link against wasi-libc forever, because its expected for C library interop, even if nothing in std strictly needs to use it

Alex Crichton (Apr 07 2025 at 20:31):

AFAIK many folks are in a similar boat of "would be nice to write I/O stuff in rust". I don't think there's 100% alignment amongst all stakeholders but tbh there aren't that many super active stakeholders to begin with anyway, so I don't think it would necessarily require tons of buy-in.

Otherwise for mixing things and posix-vs-wasi it's probably best to discuss in the context of possible additions to wasi-libc. My high-level goal is to avoid any one particular language/runtime leaking into wasi-libc, e.g. taking everything needed by Python and putting it in wasi-libc when something like rust's libstd wouldn't want it at all. How exactly to achieve that high level goal without Python rewriting wasi-libc is going to be a balancing act and I agree the goal is for Python and Rust, for example, to uset he same wasi-libc

Pat Hickey (Apr 07 2025 at 20:31):

also, we're working on hiring a contractor specifically to help us with wasi-libc

Alex Crichton (Apr 07 2025 at 20:32):

I may be misinterpreting Dave but my read is that we'd in theory rewrite parts of wasi-libc in Rust rather than having everything in C, specifically the non-musl portions in Rust

Alex Crichton (Apr 07 2025 at 20:32):

Pat Hickey (Apr 07 2025 at 20:32):

ah ok sorry i misread that as being just some separate rust code from wasi-libc itself

Joel Dice (Apr 07 2025 at 20:39):

What I've been envisioning is public APIs which allow code built on wasi-libc to access (and optionally swap out) the WASI-level resource(s), streams, etc. corresponding to a file descriptor. That would include taking ownership of the WASI-level handles by removing the descriptor entirely and also doing the opposite: giving wasi-libc ownership of WASI-level handles and getting a new descriptor back for them.

Dave Bakker (badeend) (Apr 07 2025 at 20:49):

That's indeed what I meant. :+1: The periphery of such a Rust library would still be rather C-esque of course, but me personally would still be more comfortable maintaining awkward looking Rust compared to the C implementation. Though I might be biased towards Rust :melting_face:

Stream: wasi

Topic: WASIP3 Update

Bailey Hayes (Jan 15 2025 at 16:20):

Bailey Hayes (Jan 15 2025 at 16:22):

Bailey Hayes (Jan 15 2025 at 16:32):

Jan 15, 2025

Bailey Hayes (Jan 15 2025 at 16:40):

Items Ready for Work

Joel Dice (Jan 15 2025 at 16:41):

Victor Adossi (Jan 15 2025 at 16:41):

Roman Volosatovs (Jan 16 2025 at 14:50):

Dave Bakker (badeend) (Jan 16 2025 at 14:52):

Pat Hickey (Jan 16 2025 at 16:05):

Joel Dice (Jan 16 2025 at 16:14):

Pat Hickey (Jan 16 2025 at 16:28):

Roman Volosatovs (Jan 17 2025 at 11:59):

Roman Volosatovs (Jan 17 2025 at 12:01):

Roman Volosatovs (Jan 17 2025 at 12:50):

Roman Volosatovs (Jan 21 2025 at 15:05):

Roman Volosatovs (Jan 21 2025 at 16:47):

Roman Volosatovs (Jan 21 2025 at 16:59):

Roman Volosatovs (Jan 21 2025 at 17:35):

Joel Dice (Jan 21 2025 at 23:43):

Roman Volosatovs (Jan 22 2025 at 13:31):

Roman Volosatovs (Jan 22 2025 at 18:44):

Joel Dice (Jan 22 2025 at 18:48):

Roman Volosatovs (Jan 22 2025 at 18:50):

Pat Hickey (Jan 22 2025 at 18:53):

Juniper Tyree (Jan 23 2025 at 06:42):

Pat Hickey (Jan 23 2025 at 18:03):

Pat Hickey (Jan 23 2025 at 18:04):

Pat Hickey (Jan 23 2025 at 18:04):

Roman Volosatovs (Jan 30 2025 at 18:06):

Roman Volosatovs (Jan 30 2025 at 18:07):

Roman Volosatovs (Jan 30 2025 at 18:45):

Alex Crichton (Jan 30 2025 at 21:51):

Alex Crichton (Jan 31 2025 at 18:35):

Alex Crichton (Jan 31 2025 at 18:37):

Alex Crichton (Jan 31 2025 at 18:38):

Alex Crichton (Jan 31 2025 at 18:38):

Roman Volosatovs (Feb 01 2025 at 09:13):

Joel Dice (Feb 02 2025 at 22:26):

Joel Dice (Feb 02 2025 at 22:28):

Roman Volosatovs (Feb 03 2025 at 14:06):

Joel Dice (Feb 04 2025 at 13:59):

Pat Hickey (Feb 05 2025 at 17:35):

Roman Volosatovs (Feb 05 2025 at 18:14):

Roman Volosatovs (Feb 05 2025 at 18:15):

Pat Hickey (Feb 05 2025 at 18:40):

Roman Volosatovs (Feb 05 2025 at 18:56):

Bailey Hayes (Feb 05 2025 at 19:14):

Pat Hickey (Feb 05 2025 at 22:01):

Pat Hickey (Feb 05 2025 at 22:01):

Victor Adossi (Feb 10 2025 at 17:14):

Roman Volosatovs (Feb 10 2025 at 17:30):

Joel Dice (Feb 10 2025 at 20:02):

Roman Volosatovs (Feb 11 2025 at 10:58):

Joel Dice (Feb 12 2025 at 01:33):

Roman Volosatovs (Feb 12 2025 at 15:40):

Roman Volosatovs (Feb 12 2025 at 19:12):

Joel Dice (Feb 12 2025 at 22:38):

Roman Volosatovs (Feb 13 2025 at 16:42):

Joel Dice (Feb 13 2025 at 16:46):

Joel Dice (Feb 13 2025 at 16:49):

Roman Volosatovs (Feb 13 2025 at 17:05):

Roman Volosatovs (Feb 13 2025 at 17:16):

Joel Dice (Feb 13 2025 at 17:49):

Roman Volosatovs (Feb 13 2025 at 17:54):

Joel Dice (Feb 13 2025 at 18:30):

Roman Volosatovs (Feb 13 2025 at 18:48):

Joel Dice (Feb 13 2025 at 22:38):

Victor Adossi (Feb 14 2025 at 03:03):

Joel Dice (Feb 14 2025 at 04:16):

Joel Dice (Feb 14 2025 at 21:54):

Joel Dice (Feb 14 2025 at 21:57):

Joel Dice (Feb 14 2025 at 22:00):

Roman Volosatovs (Feb 19 2025 at 13:01):

Joel Dice (Feb 19 2025 at 14:23):

Roman Volosatovs (Feb 19 2025 at 15:26):

Joel Dice (Feb 19 2025 at 15:27):