From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHu1X-0002jc-C3 for qemu-devel@nongnu.org; Tue, 19 Mar 2013 06:44:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHu1W-0000IH-2Y for qemu-devel@nongnu.org; Tue, 19 Mar 2013 06:44:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51442) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHtsa-00064h-E9 for qemu-devel@nongnu.org; Tue, 19 Mar 2013 06:34:52 -0400 Message-ID: <51483F41.5000800@redhat.com> Date: Tue, 19 Mar 2013 11:34:41 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1363154346-14827-1-git-send-email-qemulist@gmail.com> <51405BEA.6080109@redhat.com> <87hakfiild.fsf@codemonkey.ws> <87r4jbn3d1.fsf@blackfin.pond.sub.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/2] port network layer onto glib List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: mdroth , "Michael S. Tsirkin" , Stefan Hajnoczi , qemu-devel@nongnu.org, Markus Armbruster , Anthony Liguori , Liu Ping Fan Il 19/03/2013 11:12, Peter Maydell ha scritto: > On 19 March 2013 09:30, Markus Armbruster wrote: >> Coroutines are a perfectly pedestrian control flow construct. > > In some languages, sure. Not in C, and we're writing C. > >> Coroutines fit about as well with C as threads, namely not really. > > Threads are supported by the language runtime provided on all > the systems we support, which is why they are reasonably usable. > When you've persuaded glibc, MacOSX libc and Windows to implement > coroutines please come back and let me know :-) Windows supports them (it calls them fibers) and glibc does on many architectures (all but ARM, basically). Paolo >> If portable coroutines in C really was an intractable problem, the >> solution could not be "no more coroutines, please", only "no coroutines, >> period". As long as we have to pay the price for coroutines anyway, I >> can't see why we should deny ourselves the benefits. > > I'd like to see coroutines gone completely. The first step is not > to let them get used more than they are already. > >> C programs have been doing coroutines since forever, using either hand >> coded assembly language stack switching, sigaltstack() trickery, >> ucontext(), w32 fibers, or some coroutine library built on top of these. > > ...and there's a wide range of really nasty options because none > of them are actually decent solutions to the problem. > > -- PMM >