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

[Andreas Färber]

Am 22.06.2012 12:59, schrieb Peter Crosthwaite:
> On Fri, Jun 22, 2012 at 6:53 PM, Kevin Wolf <address@hidden> wrote:
>> Am 22.06.2012 10:20, schrieb Peter Crosthwaite:
>>> [...] I thought that was the point of coroutines vs
>>> threads? coroutines you control yield behaviour explicitly whearas
>>> thread you cant?
>>
>> Well, I can see your point, although today no code in qemu makes use of
>> the property that the caller could in theory know where the coroutine
>> yields. I think it's also dangerous because there is a non-obvious
>> dependency of the caller on the internals of the coroutine. A simple
>> innocent looking refactoring of the coroutine might break assumptions
>> that are made here.
>>
>> Other code in qemu that uses coroutines only makes use of the fact that
>> coroutines can only be interrupted at known points,
> 
> So within the block layer, will the block coroutines yield anywhere or
> only at a qemu_coroutine_yield() site? Would the block layer break if
> a couroutine could be pre-empted by the OS anywhere?
> 
> So lets continue this to an example of multiple clients of
> qemu-coroutine. The block layer is one client. It defines three
> possible yields points (qemu_co_yield() sites) in block.c. Lets call
> them A,B and C. The co-routine policy is that your thread of control
> will not be pre-empted until locations  A, B or C are reached (I.E.
> coroutines can only be interrupted at known points). Alls fair and it
> works.
> 
> Now here is where it breaks. I have a device or machine model or
> whatever (lets call it foo) that uses co-routines. It decides that it
> wants its coroutines to stop at only at points D,E and F for ease of
> synchronization. If those coroutines however make calls into to the
> block layer, the block layer will think its in its own co-routine and
> potentially yield at any of points A,B and C. Thing is, my foo system
> doesn't care about the block layer implementation, so it shouldnt have
> awareness of the fact it used co-routines too. But because it talks to
> block, it can get yielded as any call into the block API which is
> awkward considering the point of coroutines is they can only be
> interrupted at known points. You have essentially defeated the purpose
> or coroutines in the first place. Foo's coroutines are behaving like
> preemptible threads (while blocks are behaving like coroutines).
[snip]

Maybe I'm misunderstanding the discussion, but there's three coroutine
implementations, including one based on GThread. So in that case any
coroutine can be preempted anywhere and there are no such guarantees as
discussed here, are there?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg