From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVrg4-0004g3-B4 for qemu-devel@nongnu.org; Sun, 12 Jun 2011 16:54:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QVrg2-0000DS-Dz for qemu-devel@nongnu.org; Sun, 12 Jun 2011 16:54:36 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:53791) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVrg2-0000DM-40 for qemu-devel@nongnu.org; Sun, 12 Jun 2011 16:54:34 -0400 Received: by ywl41 with SMTP id 41so2228124ywl.4 for ; Sun, 12 Jun 2011 13:54:33 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <201106111427.28579.roucaries.bastien@gmail.com> References: <1307641266-7726-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <201106111427.28579.roucaries.bastien@gmail.com> Date: Sun, 12 Jun 2011 21:54:32 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] coroutine: Implement coroutines using gthread List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bastien ROUCARIES Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, "Aneesh Kumar K.V" On Sat, Jun 11, 2011 at 1:27 PM, Bastien ROUCARIES wrote: > Le jeudi 9 juin 2011 19:41:06, Aneesh Kumar K.V a =E9crit : >> On platforms that doesn't support makecontext use gthread >> based coroutine implementation. > > Why not using one of the existing lib of coroutine or improving it ? > > Could you give some hints ? > > Why not use http://cvs.schmorp.de/libcoro/coro.h what is the base of the = perl coroutine lib and thus well tested on a lot of > plateform? libcoro provides a different API where you need to know which coroutine called you in order to yield back to it later. Since the common use-case is to transfer control to a coroutine and then have it yield back, this caller information is very handy and avoids littering code with explicit caller variables. We have ucontext, Win32 Fibers, and now GThread implementations of coroutines. I think it's not worth switching to libcoro because it is just a little different with its own quirks and limitations, not clearly better. This code actually started out from the gtk-vnc coroutines implementation, so we did start by reusing code... :) Stefan