From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KYPxp-0006zT-MH for qemu-devel@nongnu.org; Wed, 27 Aug 2008 14:41:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KYPxm-0006wL-KL for qemu-devel@nongnu.org; Wed, 27 Aug 2008 14:41:53 -0400 Received: from [199.232.76.173] (port=50555 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KYPxm-0006w2-CX for qemu-devel@nongnu.org; Wed, 27 Aug 2008 14:41:50 -0400 Received: from mail2.shareable.org ([80.68.89.115]:42467) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KYPxl-0003UI-LC for qemu-devel@nongnu.org; Wed, 27 Aug 2008 14:41:50 -0400 Date: Wed, 27 Aug 2008 19:41:46 +0100 From: Jamie Lokier Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals. Message-ID: <20080827184146.GD27491@shareable.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18613.33339.351040.938403@mariner.uk.xensource.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Jackson Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, Gerd Hoffmann Ian Jackson wrote: > > > If you use aio, glibc has a tendency to emulate it with thread(s). > > > The helper thread I was referring to in my commit message is the > > > glibc-created helper thread. glibc appears (in strace) to do IO in > > > this thread and then raises the signal you asked for (SIGUSR2 in > > > qemu's case). > > > > That observation implies Anthony's helper thread will not always > > receive the SIGUSR2 signals - Glibc's thread may receive them instead. > > Yes. Err, I'm not sure what effect that will have in Anthony's patch > but it probably wouldn't be good. > > As I say I haven't managed to reproduce this other than in a full > qemu-dm tree (from qemu-xen). > > So it may be that it is because of something I did or something the > qemu-xen code does - although it seems hard to imagine how it could > break the signal mask in the helper thread given that that thread runs > entirely glibc code, except when a signal is being delivered (and of > course the signal mask is saved and restored for signal delivery). It's not your fault. 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. (This might be a Glibc bug - threads you don't know about shouldn't be receiving your signals, should they?) That means if it wasn't masked when you issued the first AIO request, it won't be masked in that thread. It's quite annoying that POSIX threads doesn't provide any way to say "mask this signal in all other threads", which you often want to do from a library. -- Jamie