Port wasmtime-fiber to no_std and allow async feature in no_std Wasmtime.
#9689
Conversation
|
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
| } | ||
| #[cfg(not(feature = "std"))] | ||
| { | ||
| result = Ok((func)(initial, &mut suspend)); |
There was a problem hiding this comment.
If you do unwind when the std feature is disabled, are you guaranteed to hit an extern "C" boundary to abort unwinding? Or will you get arbitrary corruption?
There was a problem hiding this comment.
Excellent question! (@alexcrichton when you're around it'd be great to get your canonical answer on this)
Currently in my porting context I have a #[panic_handler] that will abort, so I haven't thought through this in much detail. One option is certainly to say that panic unwinding is not supported in no_std builds with async, and the build must provide a custom aborting panic handler or specify panic=abort. However if we wanted to support propagation of unwinds I think we might be able to do something custom here (the catch_unwind/resume_unwind functions in std::panic don't exist in core::panic but one could roll one's own unwinding). I wonder if there's a way to make this safe (build only when panic=abort for example) in the meantime?
There was a problem hiding this comment.
@sunfishcode helpfully pointed out that #[cfg(panic = "unwind")] and #[cfg(panic = "abort")] work, so I've added a compile_error!() to the fiber library when built with panic=unwind without std. So this is at least now safe!
cfallin
force-pushed
the
async-nostd
branch
2 times, most recently
from
1ca5f08
to
2cfc402
Compare
… 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. 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.
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.