From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG5mt-0003Sz-CG for qemu-devel@nongnu.org; Thu, 14 Mar 2013 06:53:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UG5mp-0005wb-A7 for qemu-devel@nongnu.org; Thu, 14 Mar 2013 06:53:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54204) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG5mp-0005wV-2k for qemu-devel@nongnu.org; Thu, 14 Mar 2013 06:53:27 -0400 Message-ID: <5141AC1F.3030203@redhat.com> Date: Thu, 14 Mar 2013 11:53:19 +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> 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, Liu Ping Fan , Anthony Liguori Il 14/03/2013 11:04, Peter Maydell ha scritto: > On 13 March 2013 12:34, Anthony Liguori wrote: >> AioContext is necessary for the block layer because the block layer >> still has synchronous I/O. I think we should aim to replace all sync >> I/O in the long term with coroutine based I/O. > > I think coroutines are dreadful and we should really not be moving > towards greater use of them. They're just really really not portable > and they don't fit with the C language, and they're a constant source > of problems.(For instance I have a bug I need to look into where we > seem to hang using the gthread coroutine backend but not sigaltstack.) The gthread coroutine backend is really more for debugging than anything else. It works for qemu-io/img, but not for QEMU. Good that you actually found proof. :) Paolo > Use threads, or a genuinely asynchronous API, or a select/poll loop > with callbacks, but not more coroutines please. > > -- PMM >