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