From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KY0UO-0001W8-2z for qemu-devel@nongnu.org; Tue, 26 Aug 2008 11:29:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KY0UM-0001UP-3g for qemu-devel@nongnu.org; Tue, 26 Aug 2008 11:29:47 -0400 Received: from [199.232.76.173] (port=46708 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KY0UL-0001UB-SY for qemu-devel@nongnu.org; Tue, 26 Aug 2008 11:29:45 -0400 Received: from il.qumranet.com ([212.179.150.194]:43703) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KY0UL-0007Ot-FA for qemu-devel@nongnu.org; Tue, 26 Aug 2008 11:29:45 -0400 Message-ID: <48B42168.2020706@qumranet.com> Date: Tue, 26 Aug 2008 18:29:44 +0300 From: Avi Kivity 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> <18612.8170.439324.706002@mariner.uk.xensource.com> In-Reply-To: <18612.8170.439324.706002@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: > Avi Kivity writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals."): > >> Not sure that it matters, but the semantics are slightly different: >> with a thread you don't get EINTR in random syscalls as the signal >> thread is the only one that has the signals unblocked. >> > > That's true but I don't think it's really relevant because we already > have other signal handlers (and we might grow further ones) so the > rest of the code has to be robust against those. > > My experience suggests very strongly that we should avoid doing > multithreaded things if at all possible. Threads are less portable; > even when they are provided many of the implementations are buggy > (although less so nowadays). > > There is also the way that once you have a multithreaded program, it > is much more difficult to discourage the expansion of the concurrent > functionality until the whole program is a mass of race bugs. I would > rather not open this stable door. > > In this case the thread is only used to emulate the signalfd() system call; it is not part of qemu proper. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals. Date: Tue, 26 Aug 2008 18:29:44 +0300 Message-ID: <48B42168.2020706@qumranet.com> 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> <18612.8170.439324.706002@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <18612.8170.439324.706002@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: qemu-devel@nongnu.org Cc: xen-devel@lists.xensource.com, Gerd Hoffmann List-Id: xen-devel@lists.xenproject.org Ian Jackson wrote: > Avi Kivity writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals."): > >> Not sure that it matters, but the semantics are slightly different: >> with a thread you don't get EINTR in random syscalls as the signal >> thread is the only one that has the signals unblocked. >> > > That's true but I don't think it's really relevant because we already > have other signal handlers (and we might grow further ones) so the > rest of the code has to be robust against those. > > My experience suggests very strongly that we should avoid doing > multithreaded things if at all possible. Threads are less portable; > even when they are provided many of the implementations are buggy > (although less so nowadays). > > There is also the way that once you have a multithreaded program, it > is much more difficult to discourage the expansion of the concurrent > functionality until the whole program is a mass of race bugs. I would > rather not open this stable door. > > In this case the thread is only used to emulate the signalfd() system call; it is not part of qemu proper. -- error compiling committee.c: too many arguments to function