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
