On 07/08/2013 20:18, Stefan Hajnoczi wrote:
On Mon, Aug 05, 2013 at 08:44:04PM +0200, Charlie Shepherd wrote:
From: Charlie Shepherd <cs...@cam.ac.uk>
While it only really makes sense to call qemu_coroutine_self() in a coroutine
context, it cannot actually yield execution itself, so remove the coroutine_fn
annotation.
---
include/block/coroutine.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
By removing coroutine_fn the rules have changed:
It's now legal to call qemu_coroutine_self() outside a coroutine.
Previously only callers that knew the internals of the coroutine
implementation did that.
Yes, I agree that it's probably not helpful to loosen the restrictions
on when its possible to call qemu_coroutine_self().
coroutine_fn gives coroutine backend implementors more flexibility in
how they choose to implement qemu_coroutine_self(). From an API
perspective I prefer to keep qemu_coroutine_self() marked as a
coroutine_fn.
I guess the practical problem is that CPC will get
upset that it's being called by the coroutine implementation from
non-coroutine contexts. This can be solved:
1. Keep the public qemu_coroutine_self() marked coroutine_fn.
2. Have it call an internal coroutine_self() function that is not
coroutine_fn.
This way the API stays strict and the internal implementation doesn't
violate the coroutine_fn calling rule.
This is a good solution, I'll add a patch implementing it to the series.
Charlie
