From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KcAEW-0002jM-EH for qemu-devel@nongnu.org; Sat, 06 Sep 2008 22:42:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KcAES-0002jA-Va for qemu-devel@nongnu.org; Sat, 06 Sep 2008 22:42:35 -0400 Received: from [199.232.76.173] (port=39866 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcAES-0002j7-SV for qemu-devel@nongnu.org; Sat, 06 Sep 2008 22:42:32 -0400 Received: from an-out-0708.google.com ([209.85.132.240]:54413) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KcAES-0002l1-FZ for qemu-devel@nongnu.org; Sat, 06 Sep 2008 22:42:32 -0400 Received: by an-out-0708.google.com with SMTP id d18so163222and.130 for ; Sat, 06 Sep 2008 19:42:32 -0700 (PDT) Message-ID: <48C33F67.4060901@codemonkey.ws> Date: Sat, 06 Sep 2008 21:41:43 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals. References: <18612.1900.73781.314743@mariner.uk.xensource.com> <48B41B7E.40708@codemonkey.ws> <18612.7267.832361.270651@mariner.uk.xensource.com> <48B41F55.1000909@codemonkey.ws> <18612.8502.305043.233934@mariner.uk.xensource.com> <48B422F2.1090900@codemonkey.ws> <20080826174729.GB25893@shareable.org> <18613.8801.187470.178088@mariner.uk.xensource.com> <20080827162719.GC25387@shareable.org> <18613.33339.351040.938403@mariner.uk.xensource.com> <20080827184146.GD27491@shareable.org> <18614.28941.823723.388725@mariner.uk.xensource.com> In-Reply-To: <18614.28941.823723.388725@mariner.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: xen-devel@lists.xensource.com, Gerd Hoffmann Ian Jackson wrote: > Jamie Lokier writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals."): > >> A quick read of Glibc 2.3.1 source says its AIO code does not change >> the signal mask when it creates an AIO handling thread. >> > > Thanks for investigating that. > > >> (This might be a Glibc bug - threads you don't know about shouldn't be >> receiving your signals, should they?) >> > > Yes, it's a bug. (I wonder why my test program didn't expose it.) > > >> That means if it wasn't masked when you issued the first AIO request, >> it won't be masked in that thread. >> > > In practice since we use aio this probably means we can't rely on > signal blocking except for signals which qemu keeps blocked `nearly > all' the time. So pipe-to-self in the signal handler is the way to > go. > In my signalfd patch, we block SIGUSR2 all the time so it shouldn't be affected by this "bug". We use sigwait or signalfd to receive the signal. Regards, Anthony Liguori