From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V79FO-0001Eg-9Y for qemu-devel@nongnu.org; Wed, 07 Aug 2013 15:18:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V79FJ-0006wF-AG for qemu-devel@nongnu.org; Wed, 07 Aug 2013 15:18:14 -0400 Received: from mail-bk0-x22f.google.com ([2a00:1450:4008:c01::22f]:54190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V79FJ-0006vI-3h for qemu-devel@nongnu.org; Wed, 07 Aug 2013 15:18:09 -0400 Received: by mail-bk0-f47.google.com with SMTP id mx12so384975bkb.6 for ; Wed, 07 Aug 2013 12:18:08 -0700 (PDT) Date: Wed, 7 Aug 2013 21:18:05 +0200 From: Stefan Hajnoczi Message-ID: <20130807191805.GA16226@stefanha-thinkpad.hitronhub.home> References: <1375728247-1306-1-git-send-email-charlie@ctshepherd.com> <1375728247-1306-3-git-send-email-charlie@ctshepherd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1375728247-1306-3-git-send-email-charlie@ctshepherd.com> 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: Charlie Shepherd Cc: kwolf@redhat.com, pbonzini@redhat.com, Charlie Shepherd , gabriel@kerneis.info, qemu-devel@nongnu.org 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. 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. Stefan