qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption
Date: Fri, 29 Jun 2012 18:39:28 +1000


On Jun 29, 2012 6:24 PM, "Kevin Wolf" <address@hidden> wrote:
>
> Am 29.06.2012 02:50, schrieb Peter Crosthwaite:
> >>
> >> The problem I see is:
> >>
> >> FDTMachineInfo *fdt_generic_create_machine()
> >> {
> >>    ...
> >>    while (qemu_co_queue_enter_next(fdti->cq));
> >> }
> >>
> >> The problem you have is not that the block layer is yielding.  The
> >> problem is that you need to run aio processing
> >
> > And this is what Im trying to say is wrong. My usage of coroutine has
> > nothing to do with block, AIO or any other existing client of
> > coroutine. I shouldnt have to make API calls into things I dont care
> > about just to make my coroutines work. The QOM people should be able
> > to come along and rewrite the AIO subsystem tommorow and it shouldnt
> > affect my coroutines.
>
> This isn't really block or AIO specific. What you need to run is
> basically a nested main loop. As long as you process the
> (aio_)fd_handlers and bottom halves, the block layer will work.
> qemu_aio_wait() implements such a nested main loop. I think the only
> major thing that is not executed in qemu_aio_wait() is timers (and maybe
> that's something we should change).
>
> > Maybe I need to generalise away from block. This problem goes a level
> > higher to AIO. AIO is assuming it owns all coroutines - I.E. if you
> > are in coroutines context (qemu_in_coroutine()) then that coroutine
> > can be pre-emented and queued up in AIO's work queue. Im saying this
> > is flawed - because it means coroutines are not generic, they are for
> > AIO use only.
> >
> > So change subject to "Remove assumption that AIO owns coroutines".
>
> No, the assumption is a completely different one and it has nothing to
> do with who "owns" a coroutine. It is about whether you may assume that
> a call into a different subsystem doesn't yield. The answer today is no,
> the other subsystem may yield. You want to change it to yes.

Then can we change it to yes? If subsystems yield coroutines without checks then PMM is right, coroutines are just obfuiscated threads...

But there's
> nothing AIO or block specific about it.
>
> Kevin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]