From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNOsz-0004pf-L7 for qemu-devel@nongnu.org; Fri, 20 May 2011 08:32:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QNOsu-00026D-Rf for qemu-devel@nongnu.org; Fri, 20 May 2011 08:32:57 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:52087) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNOsu-000269-Ny for qemu-devel@nongnu.org; Fri, 20 May 2011 08:32:52 -0400 Received: by yxk8 with SMTP id 8so1481360yxk.4 for ; Fri, 20 May 2011 05:32:52 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4DD659E9.7020501@redhat.com> References: <1305889177-10490-1-git-send-email-stefanha@linux.vnet.ibm.com> <1305889177-10490-2-git-send-email-stefanha@linux.vnet.ibm.com> <4DD659E9.7020501@redhat.com> Date: Fri, 20 May 2011 13:32:51 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 1/3] coroutine: introduce coroutines List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Anthony Liguori , Stefan Hajnoczi , qemu-devel@nongnu.org, Blue Swirl , Venkateswararao Jujjuri On Fri, May 20, 2011 at 1:09 PM, Paolo Bonzini wrote: > On 05/20/2011 12:59 PM, Stefan Hajnoczi wrote: >> >> This coroutines implementation is based on the gtk-vnc implementation >> written by Anthony Liguori =A0but it has been >> significantly rewritten by Kevin Wolf =A0to use >> setjmp()/longjmp() instead of the more expensive swapcontext() and by >> Paolo Bonzini =A0for Windows Fibers support. >> > > Not a blocker at all, but why did you move the pooling to the ucontext > implementation? =A0It's less expensive to create the fiber in Windows bec= ause > there are no system calls (unlike swapcontext), but a future pthread-base= d > implementation will also need the pooling. > > It can be left to whoever writes the pthread stuff, though. There are two options for pooling: 1. Thread-local pools 2. One global pool with a lock One of these choices must be selected because otherwise the pool could be accessed simultaneously from multiple threads. I tried #2 first because it was less code but it caused a noticable slow-down with ./check-coroutine --benchmark-lifecycle. Option #1 had less impact but requires using thread-local storage, which I've used pthread APIs for. Hence I moved it into coroutine-ucontext.c hoping that win32 would either be fast enough as-as or that we could find a better solution if someone needs it. Stefan