From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47165) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKWcf-0005T3-Dy for qemu-devel@nongnu.org; Tue, 26 Mar 2013 12:21:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKWcc-0007dk-M2 for qemu-devel@nongnu.org; Tue, 26 Mar 2013 12:21:17 -0400 Received: from mail-bk0-x22f.google.com ([2a00:1450:4008:c01::22f]:54674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKWcc-0007dJ-Bn for qemu-devel@nongnu.org; Tue, 26 Mar 2013 12:21:14 -0400 Received: by mail-bk0-f47.google.com with SMTP id ik5so1180479bkc.34 for ; Tue, 26 Mar 2013 09:21:13 -0700 (PDT) Date: Tue, 26 Mar 2013 17:21:10 +0100 From: Stefan Hajnoczi Message-ID: <20130326162110.GA3391@stefanha-thinkpad.redhat.com> References: <51510CE8.7090208@linux.vnet.ibm.com> <51514856.8010405@redhat.com> <20130326095455.GD24025@stefanha-thinkpad.redhat.com> <51517289.1020909@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51517289.1020909@redhat.com> Subject: Re: [Qemu-devel] coroutine: hung when using gthread backend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Wenchao Xia , qemu-devel On Tue, Mar 26, 2013 at 11:03:53AM +0100, Paolo Bonzini wrote: > Il 26/03/2013 10:54, Stefan Hajnoczi ha scritto: > > On Tue, Mar 26, 2013 at 08:03:50AM +0100, Paolo Bonzini wrote: > >> Il 26/03/2013 03:50, Wenchao Xia ha scritto: > >>> When I using tcg with coroutine backend = gthread, > >>> x86_64-softmmu/qemu-system-x86_64 will hung. Any one > >>> working on it? > >> > >> coroutine backend gthread hardly works for qemu, only qemu-io and qemu-img. > > > > Do you know why it doesn't work? > > Because it screws up the signals. Coroutines can start in a thread and > later move to another. If you use the gthread backend, coroutines keep > the signal mask of the thread where they were created. > > It is basically the same bug that was fixed in commit 6ab7e54 (Replace > all setjmp()/longjmp() with sigsetjmp()/siglongjmp(), 2013-02-20). That's interesting. Maybe it can be fixed if the gthread backend is actually needed. Stefan