Re: [PATCH 04/11] rust/qemu-api: Add wrappers to run futures in QEMU

[Kevin Wolf]

Am 12.02.2025 um 14:22 hat Paolo Bonzini geschrieben:
> > > 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 idea was that you don't call the correct function but the *only*
> function :) i.e. exec.run_until(), and it will do the right thing for
> coroutine vs. no coroutine.
> 
> But yeah, there would be boilerplate to pass it all the way down so
> maybe it is not a great idea. I liked the concept that you just
> *couldn't* get _co_ wrong... but perhaps it is not necessary once more
> of "BlockDriver::open"
> is lifted into bdrv_open<D: BlockDriver>.

Yes, my assumption is that in the final state there is no "all the way
down" because the function wanting to run a future will be the outermost
Rust function. At any other level, the Rust function can just be async
itself.

That's why I said that calling the only function of the correct executor
isn't really any better than directly calling the correct function.

Kevin