Port wasmtime-fiber to no_std and allow async feature in no_std Wasmtime.#9689
Port wasmtime-fiber to no_std and allow async feature in no_std Wasmtime.#9689cfallin merged 1 commit intobytecodealliance:mainfrom
no_std and allow async feature in no_std Wasmtime.#9689Conversation
|
cc @alexcrichton -- I think you're on vacation now but I'd be very curious what you think of this in general! |
cfallin
changed the title
no_std and allow async feature in no_std…no_std and allow async feature in no_std Wasmtime.
github-actions
bot
added
the
wasmtime:api
cfallin
force-pushed
the
async-nostd
branch
3 times, most recently
from
2cfc402 to
dc4fe18
Compare
alexcrichton
left a comment
alexcrichton
left a comment
There was a problem hiding this comment.
This all looks quite reasonable to me, happy to see this merged 👍.
Could you also add a cargo test -p wasmtime-fiber --no-default-features in CI? I generally try to make sure that if there's nontrivial code added with no_std/etc (as is the case for the nostd.rs file here) that we have some at least smoke testing of what's going on. I think that this should be testable when the std feature is disabled? (might have to conditionally enable/disable some panicking tests, and it's ok to use std in tests just want to be sure to test nostd.rs somehow)
|
Updated and out of draft mode now; thanks! |
alexcrichton
left a comment
alexcrichton
left a comment
There was a problem hiding this comment.
Is it possible to add a `cargo test -p wasmtime-fiber --no-default-features to CI as well?
cfallin
force-pushed
the
async-nostd
branch
2 times, most recently
from
682e9b1 to
1ff8b54
Compare
|
Sure thing, done! |
… Wasmtime. (#9689) This PR allows a `no_std` Wasmtime build to be configured with the `async` feature. (Previously, a minimal `no_std` configuration could only run with sync entry points, without suspending of stacks.) The main hurdle to this support was the `wasmtime-fiber` crate. Fortunately, the "unix" variant of fibers was almost entirely portable to a `no_std` environment, owing to the fact that it implements stack-switching manually in assembly itself. I moved the per-ISA implementations to a shared submodule and built the nostd platform backend for `wasmtime-fiber` with a stripped-down version of the unix backend. The nostd backend does not support mmap'd stacks, does not support custom stack allocators, and does not propagate panics. I've updated the `min-platform` example to ensure this builds but have not yet actually tested it (I am in the middle of a larger porting effort); hence, a draft PR for initial feedback.
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
|
The CI failures are fairly perplexing -- the only failing job I see is "report failure on cancelation", and a bunch of other jobs are canceled midway through their runs. @alexcrichton any ideas? |
|
This happened on another PR the other night and I couldn't figure out what was happening. I then re-queued in the morning and it merged so I assumed it was a transient failure in CI infrastructure... Let's see if that still holds true? |
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
|
I've pushed a commit to run full CI on this PR where the PR run can't cancel itself, so let's see what happens... |
|
Bleh ok so this is a known issue (at least to me) on github actions. For the merge queue there's no way to cancel a failed job so our In any case it's the Windows build. Just some minor things to update. |
cfallin
force-pushed
the
async-nostd
branch
2 times, most recently
from
b00174c to
65d9ef8
Compare
|
Ah, that was entirely unintuitive, GitHub CI user-interface! Thanks for working that out. |
… Wasmtime. This PR allows a `no_std` Wasmtime build to be configured with the `async` feature. (Previously, a minimal `no_std` configuration could only run with sync entry points, without suspending of stacks.) The main hurdle to this support was the `wasmtime-fiber` crate. Fortunately, the "unix" variant of fibers was almost entirely portable to a `no_std` environment, owing to the fact that it implements stack-switching manually in assembly itself. I moved the per-ISA implementations to a shared submodule and built the nostd platform backend for `wasmtime-fiber` with a stripped-down version of the unix backend. The nostd backend does not support mmap'd stacks, does not support custom stack allocators, and does not propagate panics. prtest:full
3 participants
This PR allows a
no_stdWasmtime build to be configured with theasyncfeature. (Previously, a minimalno_stdconfiguration could only run with sync entry points, without suspending of stacks.)The main hurdle to this support was the
wasmtime-fibercrate. Fortunately, the "unix" variant of fibers was almost entirely portable to ano_stdenvironment, owing to the fact that it implements stack-switching manually in assembly itself. I moved the per-ISA implementations to a shared submodule and built the nostd platform backend forwasmtime-fiberwith a stripped-down version of the unix backend.The nostd backend does not support mmap'd stacks, does not support custom stack allocators, and does not propagate panics.
I've updated the
min-platformexample to ensure this builds but have not yet actually tested it (I am in the middle of a larger porting effort); hence, a draft PR for initial feedback.