From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KY0bT-00084C-IM for qemu-devel@nongnu.org; Tue, 26 Aug 2008 11:37:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KY0bR-00081r-NT for qemu-devel@nongnu.org; Tue, 26 Aug 2008 11:37:06 -0400 Received: from [199.232.76.173] (port=57558 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KY0bR-00081a-Gw for qemu-devel@nongnu.org; Tue, 26 Aug 2008 11:37:05 -0400 Received: from an-out-0708.google.com ([209.85.132.246]:19182) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KY0bQ-0000nz-Oz for qemu-devel@nongnu.org; Tue, 26 Aug 2008 11:37:05 -0400 Received: by an-out-0708.google.com with SMTP id d18so359750and.130 for ; Tue, 26 Aug 2008 08:37:04 -0700 (PDT) Message-ID: <48B422F2.1090900@codemonkey.ws> Date: Tue, 26 Aug 2008 10:36:18 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals. References: <1219336054-15919-1-git-send-email-kraxel@redhat.com> <1219336054-15919-2-git-send-email-kraxel@redhat.com> <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> In-Reply-To: <18612.8502.305043.233934@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: Ian Jackson Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, Gerd Hoffmann Ian Jackson wrote: > Anthony Liguori writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals."): > >> Then you need a pipe per-signal and you can't accurately simulate >> threadfd() (since you can't communicate siginfo). >> > > No, you don't need a pipe per signal. You only need multiple pipes if > you have multiple different event loops which are each capable of > handling only a subset of the signals, _and_ you're unwilling to use > an atomic flag variable (eg, cpu_interrupt) or its equivalent. > > But we already have cpu_interrupt, and of course the aio completion > system has its own recording of what's going on. So that does not > apply to qemu. > > All that's needed is a reliable, race-free, way of avoiding spuriously > blocking in a syscall when an event occurs between checking the state > variables (aio_error, cpu interrupt check) and the call to select(). > One fd is sufficient for that. > > Just to make that concrete, even if we extended my patch to use its > mechanism for SIGINT et al I don't think a second pipe would be > needed. > 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. >> I don't see threads as a problem. Are you concerned about mini-OS? >> > > Minios certainly doesn't currently have any threads and it would > probably be a severe pain to introduce them. That's just one example > of a portability problem. > We're definitely not going to avoid threads forever in QEMU. KVM requires threads to support multiple VCPUs. Threads are also needed to support true SMP with TCG. And right now, implementing a thread pool is the only sane way to get reasonable disk IO in userspace. I share your concerns about threading, which is why we have to use them in a very careful way. My signalfd() patch uses them in a very isolated way that is pretty easily verified. You could always add proper signalfd() support to minios. You can also certainly implement a signalfd() emulation that uses pipe(). signalfd() is really the right solution to this problem (and it doesn't require threads by default). Regards, Anthony Liguori > Ian. >