qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/5] qemu_coroutine_self should not be marked co


From: Charlie Shepherd
Subject: Re: [Qemu-devel] [PATCH 2/5] qemu_coroutine_self should not be marked coroutine_fn as it cannot yield
Date: Thu, 08 Aug 2013 10:10:18 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

On 08/08/2013 07:16, Gabriel Kerneis wrote:
On Thu, Aug 08, 2013 at 02:29:39AM +0100, Charlie Shepherd wrote:
On 07/08/2013 23:13, Gabriel Kerneis wrote:
On Wed, Aug 07, 2013 at 09:18:05PM +0200, Stefan Hajnoczi wrote:
I guess the practical problem is that CPC will get
upset that it's being called by the coroutine implementation from
non-coroutine contexts.
But is it really the case? If Charlie added an annotation, it probably means
that in practice it was only called from coroutine context anyway.
It was also called from coroutine implementation in functions that
weren't annotated coroutine_fn (qemu_coroutine_switch() and
friends).
In that case, the interface/implementation split suggested by Stefan makes
sense.

Note that qemu_coroutine_self() in principle really needs to be annotated
coroutine_fn since it accesses (and returns) its execution context. The fact
that it is implemented with thread-local variables in Qemu is an implementation
detail, almost a hack (however smart); the "natural" CPC way would be to just
return the coroutine associated with the current continuation. So keeping the
annotation definitely makes sense.

While that would be the natural way, we are going to need the thread local variables regardless due to the use of the "leader" coroutine I believe (Stefan is this correct?). Also implementing the split in the way Stefan suggests would mean it's not possible to return the CPC continuation without a hack like the last hack I did for qemu_coroutine_yield(), as internal_qemu_coroutine_self() (I guess this function needs a better name too) would be marked as non coroutine across all coroutine implementions (ie in coroutine_int.h).


Charlie



reply via email to

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