From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KY19P-00057D-UM for qemu-devel@nongnu.org; Tue, 26 Aug 2008 12:12:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KY19O-00055y-2Y for qemu-devel@nongnu.org; Tue, 26 Aug 2008 12:12:11 -0400 Received: from [199.232.76.173] (port=53250 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KY19N-00055p-SA for qemu-devel@nongnu.org; Tue, 26 Aug 2008 12:12:09 -0400 Received: from il.qumranet.com ([212.179.150.194]:49629) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KY19M-0000k0-VR for qemu-devel@nongnu.org; Tue, 26 Aug 2008 12:12:09 -0400 Message-ID: <48B42B57.2070301@qumranet.com> Date: Tue, 26 Aug 2008 19:12:07 +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> <18612.9061.534326.657959@mariner.uk.xensource.com> In-Reply-To: <18612.9061.534326.657959@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."): > >> Ian Jackson wrote: >> >>> 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. >> > > That doesn't make us any less exposed to bugs in the threading > implementation, and is only of marginal use if anything for explaining > to people why we shouldn't have a Windows-style multithreaded bug > pile. > > Threading bugs in the implementation? In 2008? Practically all serious software is multithreaded nowadays. > Also, I think messing about with Linux-specific syscalls and then > emulating them is hardly a sensible way to carry on, when the > alternative is portable and simple. This has merit; though signalfd() will be a lot faster than catching a signal and writing to a pipe. In particular, delivering a signal to userspace has to save the floating point context, while signalfd() avoids it. With the signals used to signal I/O completion, this matters. -- 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 19:12:07 +0300 Message-ID: <48B42B57.2070301@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> <18612.9061.534326.657959@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.9061.534326.657959@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."): > >> Ian Jackson wrote: >> >>> 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. >> > > That doesn't make us any less exposed to bugs in the threading > implementation, and is only of marginal use if anything for explaining > to people why we shouldn't have a Windows-style multithreaded bug > pile. > > Threading bugs in the implementation? In 2008? Practically all serious software is multithreaded nowadays. > Also, I think messing about with Linux-specific syscalls and then > emulating them is hardly a sensible way to carry on, when the > alternative is portable and simple. This has merit; though signalfd() will be a lot faster than catching a signal and writing to a pipe. In particular, delivering a signal to userspace has to save the floating point context, while signalfd() avoids it. With the signals used to signal I/O completion, this matters. -- error compiling committee.c: too many arguments to function