|
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 02:25:17 +0100 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 |
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 <address@hidden> 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
[Prev in Thread] | Current Thread | [Next in Thread] |