From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Brook Subject: Re: [Qemu-devel] Re: [PATCH] Fix freezing bug in curses console Date: Sun, 1 Mar 2009 13:03:37 +0000 Message-ID: <200903011303.38741.paul@codesourcery.com> References: <20090228212116.GL20640@shareable.org> <20090301113635.GA10538@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Matthew Bloch , kvm@vger.kernel.org To: qemu-devel@nongnu.org, "Daniel P. Berrange" Return-path: Received: from mail.codesourcery.com ([65.74.133.4]:41146 "EHLO mail.codesourcery.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752963AbZCANDo (ORCPT ); Sun, 1 Mar 2009 08:03:44 -0500 In-Reply-To: <20090301113635.GA10538@redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: > > > I think it still suffers from the same race condition so today it > > > wouldn't work. You could fix the bottom half scheduling though so that > > > you could safely schedule a bottom half from a signal handler (using > > > roughly the same trick). > > > > Fwiw, it's perfectly sensible to have a single pipe which is shared by > > all signal handlers, just used to say "check for work flags set". > > And if you need the main loop to be able to distinguish signals coming > out of the pipe, then just write the signum into the pipe as a byte, > instead of a single dummy byte. Or even write the whole 'siginfo_t' > struct passed to the signal handler, and read it out in sizeof(siginfo_t) > sized chunks for processing. I don't think this will works. If the pipe buffer gets full the write will either block or you'll loose signals. 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. Paul