From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [PATCH] Fix freezing bug in curses console Date: Mon, 2 Mar 2009 16:57:52 +0000 Message-ID: <20090302165752.GB26974@shareable.org> References: <20090228212116.GL20640@shareable.org> <20090301113635.GA10538@redhat.com> <200903011303.38741.paul@codesourcery.com> <49AA968B.7000802@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Paul Brook , Matthew Bloch , kvm@vger.kernel.org To: qemu-devel@nongnu.org Return-path: Received: from mail2.shareable.org ([80.68.89.115]:49208 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757165AbZCBQ57 (ORCPT ); Mon, 2 Mar 2009 11:57:59 -0500 Content-Disposition: inline In-Reply-To: <49AA968B.7000802@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > >When using the pipe as a simple semaphore all you care about is the > >presence or absence of data. It doesn't matter if subsequent writes loose > >data (e.g. by not retrying a nonblocking write) as long as a write to an > >empty pipe succeeds. > > Yup. You need to use a global flag to distinguish the type of signal. If you have a set of BHs which can be scheduled from a signal handler, set a flag in the BH when it's scheduled, prior to the non-blocking pipe write. The select-pipe reader can then look at all eligible BHs looking for ones with the flag set. If you can enqueue them in the signal handler that's even better, but obviously beware of race conditions. Don't forget to completely drain the pipe when reading. Maybe use an eventfd instead of a pipe if you have eventfd. :-) If the signal handler might be run in different threads, you'll need to take care of memory ordering. The flag must be set before writing to the pipe, as observed by the pipe-reading thread. -- Jamie From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LeBSq-0005zd-79 for qemu-devel@nongnu.org; Mon, 02 Mar 2009 11:58:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LeBSo-0005yF-CQ for qemu-devel@nongnu.org; Mon, 02 Mar 2009 11:57:59 -0500 Received: from [199.232.76.173] (port=34296 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LeBSo-0005y7-4U for qemu-devel@nongnu.org; Mon, 02 Mar 2009 11:57:58 -0500 Received: from mail2.shareable.org ([80.68.89.115]:48293) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LeBSm-0007nI-SO for qemu-devel@nongnu.org; Mon, 02 Mar 2009 11:57:57 -0500 Date: Mon, 2 Mar 2009 16:57:52 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [PATCH] Fix freezing bug in curses console Message-ID: <20090302165752.GB26974@shareable.org> References: <20090228212116.GL20640@shareable.org> <20090301113635.GA10538@redhat.com> <200903011303.38741.paul@codesourcery.com> <49AA968B.7000802@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49AA968B.7000802@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Matthew Bloch , Paul Brook , kvm@vger.kernel.org Anthony Liguori wrote: > >When using the pipe as a simple semaphore all you care about is the > >presence or absence of data. It doesn't matter if subsequent writes loose > >data (e.g. by not retrying a nonblocking write) as long as a write to an > >empty pipe succeeds. > > Yup. You need to use a global flag to distinguish the type of signal. If you have a set of BHs which can be scheduled from a signal handler, set a flag in the BH when it's scheduled, prior to the non-blocking pipe write. The select-pipe reader can then look at all eligible BHs looking for ones with the flag set. If you can enqueue them in the signal handler that's even better, but obviously beware of race conditions. Don't forget to completely drain the pipe when reading. Maybe use an eventfd instead of a pipe if you have eventfd. :-) If the signal handler might be run in different threads, you'll need to take care of memory ordering. The flag must be set before writing to the pipe, as observed by the pipe-reading thread. -- Jamie