From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSE0I-0006NZ-SW for qemu-devel@nongnu.org; Wed, 09 May 2012 17:01:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SSE0H-00017Y-1Y for qemu-devel@nongnu.org; Wed, 09 May 2012 17:00:58 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]:41205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSE0G-00017J-R8 for qemu-devel@nongnu.org; Wed, 09 May 2012 17:00:56 -0400 Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 9 May 2012 15:00:51 -0600 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 09634C9005E for ; Wed, 9 May 2012 16:59:51 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q49KxrS3143144 for ; Wed, 9 May 2012 16:59:53 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q49KxoMA021026 for ; Wed, 9 May 2012 17:59:52 -0300 Message-ID: <4FAADAC5.3040001@us.ibm.com> Date: Wed, 09 May 2012 15:59:49 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4FAAC3A3.5040503@siemens.com> <4FAAC521.5000907@msgid.tls.msk.ru> <4FAAC6B2.7040009@siemens.com> <4FAACA0A.5040602@us.ibm.com> <4FAACC0F.9080702@siemens.com> <4FAACD2F.30702@us.ibm.com> <4FAACF69.50600@siemens.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1.1] coroutine: Avoid ucontext usage on i386 Linux host List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Kevin Wolf , Jan Kiszka , Michael Tokarev , qemu-devel On 05/09/2012 03:46 PM, Peter Maydell wrote: > On 9 May 2012 21:11, Jan Kiszka wrote: >> OK. Then what about sigaltstack (once fixed)? Is it also slower? If not, >> can we converge over it? > > sigaltstack is going to be significantly faster than the gthread > implementation (about the same speed as ucontext for coroutine > switch, a bit slower for coroutine creation). > > It suffers from the same problem of being a code path which nobody > has seriously stress tested, though. And it does at least one thing > which is "not permitted by the standards but works anyway". > >> I would really hate staying with this time bomb >> of broken RT signals unless someone tells me we will kick out all these >> coroutines rather sooner than later. > > I think that regardless of the long term choice it would be > a pretty risky decision to switch coroutine implementation > this close to release when we have the option of just using > a different signal that avoids the bug. > > Longer term (ie post 1.1) I'm strongly in favour of kicking > out coroutines, because I think there clearly is no single > solid portable implementation possible. C just isn't designed > to allow them; better not to try to swim against the current. Unfortunately, voting for code to be different doesn't actually make it different. If you're volunteering to rewrite the block layer to not require coroutines (either by using a state machine or by using re-entrant threads and fixing any locking issues associated with that) that's wonderful. But we decided to not do synchronous I/O years ago and still haven't removed it all from the tree. Coroutines got us much closer to getting rid of synchronous I/O. Regards, Anthony Liguori > > -- PMM >