From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7F2z-0008Ca-8Q for qemu-devel@nongnu.org; Wed, 07 Aug 2013 21:29:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7F2r-0005Cg-U5 for qemu-devel@nongnu.org; Wed, 07 Aug 2013 21:29:49 -0400 Received: from mail6.webfaction.com ([74.55.86.74]:37123 helo=smtp.webfaction.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7F2r-0005CX-OS for qemu-devel@nongnu.org; Wed, 07 Aug 2013 21:29:41 -0400 Message-ID: <5202F483.9020109@ctshepherd.com> Date: Thu, 08 Aug 2013 02:29:39 +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> <20130807221336.GA4393@kerneis.info> In-Reply-To: <20130807221336.GA4393@kerneis.info> 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: Gabriel Kerneis Cc: kwolf@redhat.com, Stefan Hajnoczi , Charlie Shepherd , qemu-devel@nongnu.org, pbonzini@redhat.com 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). > The only downside from CPC's point of view is that there is a cost to making a > coroutine_fn, and it's a pity to pay it when it's useless (ie. when the function > never yields anyway). Yes although in this case it won't be too high as the function will simply be Coroutine *internal_qemu_coroutine_self(void); coroutine_fn Coroutine *qemu_coroutine_self(void) { return internal_qemu_coroutine_self(); } and the original qemu_coroutine_self couldn't be inlined, so I don't think it is too prohibitive. Besides, I doubt qemu_coroutine_self() is called in many fast-paths. Charlie