From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48237) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7Eyi-0006Lg-Rp for qemu-devel@nongnu.org; Wed, 07 Aug 2013 21:25:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7Eyd-0003PH-53 for qemu-devel@nongnu.org; Wed, 07 Aug 2013 21:25:24 -0400 Received: from mail6.webfaction.com ([74.55.86.74]:35573 helo=smtp.webfaction.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7Eyd-0003Ok-03 for qemu-devel@nongnu.org; Wed, 07 Aug 2013 21:25:19 -0400 Message-ID: <5202F37D.6090609@ctshepherd.com> Date: Thu, 08 Aug 2013 02:25:17 +0100 From: Charlie Shepherd MIME-Version: 1.0 References: <1375728247-1306-1-git-send-email-charlie@ctshepherd.com> <1375728247-1306-3-git-send-email-charlie@ctshepherd.com> <20130807191805.GA16226@stefanha-thinkpad.hitronhub.home> In-Reply-To: <20130807191805.GA16226@stefanha-thinkpad.hitronhub.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/5] qemu_coroutine_self should not be marked coroutine_fn as it cannot yield List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, pbonzini@redhat.com, Charlie Shepherd , gabriel@kerneis.info, qemu-devel@nongnu.org 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 >> >> 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