From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KY2dm-0005Cb-AB for qemu-devel@nongnu.org; Tue, 26 Aug 2008 13:47:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KY2dk-00058y-2b for qemu-devel@nongnu.org; Tue, 26 Aug 2008 13:47:37 -0400 Received: from [199.232.76.173] (port=60630 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KY2dj-00058B-OV for qemu-devel@nongnu.org; Tue, 26 Aug 2008 13:47:35 -0400 Received: from mail2.shareable.org ([80.68.89.115]:43540) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KY2di-0007y4-Er for qemu-devel@nongnu.org; Tue, 26 Aug 2008 13:47:34 -0400 Date: Tue, 26 Aug 2008 18:47:30 +0100 From: Jamie Lokier Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals. Message-ID: <20080826174729.GB25893@shareable.org> References: <18611.56975.584280.471257@mariner.uk.xensource.com> <48B3F411.2020306@redhat.com> <18611.63711.631859.280983@mariner.uk.xensource.com> <48B4027C.1000008@codemonkey.ws> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48B422F2.1090900@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: xen-devel@lists.xensource.com, Ian Jackson , Gerd Hoffmann Anthony Liguori wrote: > In KVM, we do use the signal number to determine action. We could use > globals but since we're multi-threaded, that gets pretty nasty. The > same would apply to a threaded QEMU. Often one pipe per select-caller is enough, with global state to distinguish events. For signalfd() emulation, that's an array of sig_atomic_t signal_was_hit[NSIG]; (Or just `char' - in pthreads that should be safe to write, right? One bit is enough storage, but not thread safe.) However, if you depend on the signal number _combined_ with which thread receives the signal - then you're in trouble. pthread_self() should not be called from a signal handler; it's safety is not portable. Thread-local storage (__thread int x) is not portable and might not be signal safe either. All you've got left is gettid(), and that's not portable either. "signalfd helper thread writing to pipe" wouldn't solve that either. You'd need one _per_ thread that would have called signalfd() (if you had it) - in order to distinguish recipients. But that helper's handler can't tell which thread it is, and therefore which pipe to write to! But you did say you're using signalfd(). And signalfd() doesn't distinguish thread recipients (I'm surprised it doesn't). That whole meander was just an interesting but irrelevant puzzle. Leading to: why would (real) signals being used to collect AIO events anyway, if you don't have signalfd()? If you've got a helper thread, just call aio_suspend() in the helper thread. Then you can just deliver the AIO completion result to the relevant data structure or even move it off the waiting queue (pthread_mutex_lock is your friend), then wake the main waiting thread with byte written to its pipe. -- Jamie