add tasks to runtime #86
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add tasks to the wstd runtime, provided by the
async-task
crate.runtime changes
The Runtime's inner fields have been switched from an outer refcell to multiple inner refcells in order to properly
split the (runtime-checked) borrows, because a task's Waker::wake now requires a mutation of the Runtime's ready_list. The async task driven ready_list machinery replaces prior uses of
block_on
's "root" Waker machinery, so the internals ofblock_on
look a little different than before, but all of the improvements we figured out in #78 and #71 still work.Unfortunately, integrating async-task with wstd does require one single use of
unsafe
Rust. Its easy to reason about the unsoundness of this use, but this does break the crate-wide#[forbid(unsafe_code)]
, which is unfortunate. async-task does not provide a safe variant of its schedule function that lacks Send/Sync bounds. Because wstd will only run in single-threaded contexts, this Send/Sync restriction is not relevant to our use case.test changes
The tcp echo server example has been changed to spawn tasks, and used as the test case to demonstrate that tasks are
implemented properly. The test runner now exercises that many sockets can be accepted while echoes are in flight, which was not possible without adding concurrency to that test case. Tasks aren't the only way to add concurrency for this example, but they are appropriate because the accept loop is not interested in whether any particular connection fails.
When I was updating the tcp echo server example, I took care of replacing library use of wasmtime with spawning a wasmtime-cli process instead (Closes #43), and I went and implemented some conversion TODOs in wstd::net::tcp_listener so that the guest could more easily tell the host where it was listening.
All of these changes are broken out into a separate commit, to make it simpler to review them relative to the runtime changes.