In doing some experimentation round upgrading from wasmtime
11.0.1 to 12.0.0, I found that InputStream
was converted to HostInputStream
and it looks like the read
/write
are now synchronous.
I'm wondering if one of the following cases is true:
If (2) is the case, the easiest way I could think of was a tokio::runtime::Runtime
& block_on
, but that doesn't feel quite right...
HostInputStream
is still async; HostInputStream::read
is meant to be non-blocking, and there's a HostInputStream::ready
for waiting for data which is an async fn
.
It isn't entirely obvious from the trait docs; is the intent there that you can straightforwardly map it to a AsyncRead
?
i.e. attempt to read
, if you get ([], Open)
back then await ready
or something?
straightforward, no, easy, yes -- see AsyncReadStream
er that may not exist in the 12.0.0 release actually, so ignore me
no it is: https://github.com/bytecodealliance/wasmtime/blob/v12.0.0/crates/wasi/src/preview2/pipe.rs#L146
oh our docs.rs builds may have failed as they're still at 11.0.1
well in any case that's the rough idea, adaptation via tokio is provided with Async{Read,Write}Stream
Thanks for the clarification @Dan Gohman @Lann Martin @Alex Crichton , I see how it was meant to be used now!
I wasn't thinking of that interplay between ready and HostInputStream::read
Victor Adossi has marked this topic as resolved.
Tei Roberts has marked this topic as unresolved.
Tei Roberts has marked this topic as resolved.
Sorry, about that, thought the checkmark meant join as I didn't see any tooltip :sweat_smile:
this is still a work in progress https://github.com/bytecodealliance/wasmtime/pull/6877
the short story is: backpressure design is being revised to take into account that any call with a list<bytes> is going to consume the resources of the callee, so the callee has to explicitly permit how much that is allowed to consume
and also, flushing is a way to request & observe the completion of a write, since the write itself is non-blocking it cant report that it failed if that happens after the call is over. the explicit flush call allows userland to wait for completion to produce an error, or guarantee that it succeeded
Last updated: Dec 23 2024 at 14:03 UTC