Re: [Qemu-devel] [PATCH 2/5] qemu_coroutine_self should not be marked coroutine_fn as it cannot yield

[Charlie Shepherd <charlie@ctshepherd.com>]

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