Am 12.02.2025 um 10:28 hat Paolo Bonzini geschrieben:
> On 2/11/25 22:43, Kevin Wolf wrote:
> > +/// Use QEMU's event loops to run a Rust [`Future`] to completion and
> > return its result.
> > +///
> > +/// This function must be called in coroutine context. If the future isn't
> > ready yet, it yields.
> > +pub fn qemu_co_run_future<F: Future>(future: F) -> F::Output {
> > + let waker = Arc::new(RunFutureWaker {
> > + co: unsafe { bindings::qemu_coroutine_self() },
> > + })
> > + .into();
>
> into what? :) Maybe you can add the type to the "let" for clarity.
Into Waker. Do we have any idea yet how explicit we want to be with type
annotations that aren't strictly necessary? I didn't think of making it
explicit here because the only thing that is done with it is building a
Context from it, so it seemed obvious enough.
If you think that being explicit is better, then Waker::from() might
be better than adding a type name to let and keeping .into().
> > + let mut cx = Context::from_waker(&waker);
> > +
> > + let mut pinned_future = std::pin::pin!(future);
> > + loop {
> > + match pinned_future.as_mut().poll(&mut cx) {
> > + Poll::Ready(res) => return res,
>
> Alternatively, "break res" (matter of taste).
>
> > + Poll::Pending => unsafe {
> > + bindings::qemu_coroutine_yield();
> > + },
> > + }
> > + }
> > +}
> > +/// Wrapper around [`qemu_co_run_future`] that can be called from C.
> > +///
> > +/// # Safety
> > +///
> > +/// `future` must be a valid pointer to an owned `F` (it will be freed in
> > this function). `output`
> > +/// must be a valid pointer representing a mutable reference to an
> > `F::Output` where the result can
> > +/// be stored.
> > +unsafe extern "C" fn rust_co_run_future<F: Future>(
> > + future: *mut bindings::RustBoxedFuture,
> > + output: *mut c_void,
> > +) {
> > + let future = unsafe { Box::from_raw(future.cast::<F>()) };
> > + let output = output.cast::<F::Output>();
> > + let ret = qemu_co_run_future(*future);
> > + unsafe {
> > + *output = ret;
>
> This should use output.write(ret), to ensure that the output is written
> without dropping the previous value.
Oops, thanks. I need to learn that unsafe Rust still isn't C. :-)
> Also, would qemu_co_run_future() and qemu_run_future() become methods on an
> Executor later? Maybe it make sense to have already something like
>
> pub trait QemuExecutor {
> fn run_until<F: Future>(future: F) -> F::Output;
> }
>
> pub struct Executor;
> pub struct CoExecutor;
>
> and pass an executor to Rust functions (&Executor for no_coroutine_fn,
> &CoExecutor for coroutine_fn, &dyn QemuExecutor for mixed). Or would that
> be premature in your opinion?
If we could get bindgen to actually do that for the C interface, then
this could be interesting, though for most functions it also would
remain unused boilerplate. If we have to get the executor manually on
the Rust side for each function, that's probably the same function that
will want to execute the future - in which case it just can directly
call the correct function.
The long term idea should be anyway that C coroutines disappear from the
path and we integrate an executor into the QEMU main loop. But as long
as the block layer core is written in C and uses coroutines and we want
Rust futures to be able to call into coroutine_fns, that's still a long
way to go.
Kevin
