Support for `spawn` in wasi-async-runtime?

[Heap-Hop]

I noticed that futures_concurrency is used in the wasi-http-client-example to join tasks concurrently.

I’m curious about the best way to spawn async tasks in a wasi-async-runtime environment.
It could be useful for server-side such as handling socket.accept.

Would it make sense to add a dedicated spawn function, or is there an existing pattern approach for this?

Thank you.

[Heap-Hop]

WASI 0.2 is single-threaded, and fundamentally doesn't need access to a task.spawn abstraction. In sync Rust we use threads to combine parallelism + concurrency; but in async Rust we can separate the two. The futures-concurrency library provides access to any mode of concurrency you might want; meaning that in the absence of parallelism there is no reason for an executor to exist.

Instead APIs such as Vec::join and StreamGroup even provide access to the unbounded concurrency primitives people typically use "local executors" for - but without any of the scoped lifetime issues plaguing those abstractions. Here is an example of how to concurrently make two separate HTTP requests without having to rely on "local tasks":

Sorry for the delay in reading the blog Designing an Async Runtime for WASI 0.2.
I’m trying out futures_concurrency::future::FutureGroup to handle dynamic async tasks, but I’m not sure if there’s a better way to do this. Would love to hear any suggestions if you have them!

[yoshuawuyts]

oh yeah, sorry - we should probably deprecate this crate in favor of https://docs.rs/wstd/latest/wstd/.

FutureGroup, StreamGroup, and ConcurrentStream are indeed what I would recommend using right now. I'm not aware of any better abstractions at the moment - though I wish we could improve them to e.g. handle thing like retries. Maybe in the future tho!

[Heap-Hop]

Thanks for your kind explanation!

[Heap-Hop]

bytecodealliance/wstd#17