From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShzUg-0002zl-FB for qemu-devel@nongnu.org; Fri, 22 Jun 2012 04:45:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ShzUa-0001u1-4F for qemu-devel@nongnu.org; Fri, 22 Jun 2012 04:45:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShzUZ-0001tk-Rv for qemu-devel@nongnu.org; Fri, 22 Jun 2012 04:45:24 -0400 Message-ID: <4FE4309A.3090006@redhat.com> Date: Fri, 22 Jun 2012 10:45:14 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1340347459-29861-1-git-send-email-peter.crosthwaite@petalogix.com> <4FE423B0.9020702@siemens.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: stefanha@linux.vnet.ibm.com, Jan Kiszka , qemu-devel@nongnu.org, Peter Crosthwaite , edgar.iglesias@gmail.com, john.williams@petalogix.com Am 22.06.2012 10:16, schrieb Peter Maydell: > On 22 June 2012 09:00, Peter Crosthwaite > wrote: >> On Fri, Jun 22, 2012 at 5:50 PM, Jan Kiszka wrote: >>> Not sure if I understood the intention yet: Is this supposed to fix an >>> issue with the current usage of coroutines or to extend their usage >>> beyond that? In the latter case, please don't do this. We'd rather like >>> to get rid of them long term. > >> My extended usage, which is under development and not ready for the >> list. But are you saying qemu-coroutine is deprecated? If so Ill just >> re-impelement my work with threads, mutexes and condition vars, but >> coroutines are the most natural way of doing it. > > Basically coroutines are nastily unportable and we've had a set > of problems with them (as witness the fact that we have three > separate backend implementations!). There is supposedly some sort > of migration plan for getting them out of the block layer eventually; > they're a kind of halfway house for avoiding synchronous I/O there > AIUI. I would much prefer not to see any further use of them in new > code. Fundamentally C doesn't support coroutines and it's much better > to just admit that IMHO and use more idiomatic design approaches > instead. Our default coroutine implementation isn't really as portable as we wish, but while we use this in order to achieve the best performance, long term we could make gthread the default backend and keep coroutines where they are useful. The gthread backend is slower than the ucontext/sigaltstack ones, but it shouldn't make a difference in performance compared to using threads and putting exactly the same locking in place open-coded like Peter mentioned as an alternative approach. Kevin