From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFlQP-0008Pi-AQ for qemu-devel@nongnu.org; Thu, 05 Apr 2012 08:04:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFlQE-0007Xh-GG for qemu-devel@nongnu.org; Thu, 05 Apr 2012 08:04:23 -0400 Received: from david.siemens.de ([192.35.17.14]:33116) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFlQE-0007XE-6G for qemu-devel@nongnu.org; Thu, 05 Apr 2012 08:04:14 -0400 Message-ID: <4F7D8A32.5050401@siemens.com> Date: Thu, 05 Apr 2012 14:04:02 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4F7C663E.20200@redhat.com> <4F7C67BA.4000007@siemens.com> <4F7C68E2.508@redhat.com> <4F7C715E.506@siemens.com> <4F7C7928.1070404@redhat.com> <4F7C7D11.3040302@siemens.com> <4F7C82B8.8090602@siemens.com> <4F7D4F1C.3070208@redhat.com> <4F7D7A0C.9010600@siemens.com> <4F7D7D0E.4080309@redhat.com> <4F7D7F9D.5080805@siemens.com> <4F7D8227.4050108@redhat.com> In-Reply-To: <4F7D8227.4050108@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Anthony Liguori , "qemu-devel@nongnu.org" On 2012-04-05 13:29, Paolo Bonzini wrote: > Il 05/04/2012 13:18, Jan Kiszka ha scritto: >>>> Note that the thing above would be separate from EventNotifier, which is >>>> why I only mentioned as "by the way". >>>> >>>> EventNotifier and anything using eventfd/pipes would _not_ be a >>>> "QEMU-styled thread synchronization mechanism" simply because you can >>>> use it with qemu_aio_set_fd_handler. >>>> >>>> That's why I think it should be separate from qemu-threads and stay >>>> outside the QEMU namespace. >> >> Sorry, but that makes no sense to me. It is an abstraction we defined >> for QEMU usage in a way that fits precisely our (current) needs. That's >> what we did with tons of other abstractions before, so it fits very well >> here IMHO. > > EventNotifier _is not_ yet another thread synchronization primitive. It > can be used across processes, across the user/kernel boundary, and the > main loop can wait on multiple instances. QemuThread synchronization > primitives are only usable within a process, cannot be passed to the > kernel, and cannot signal the main loop. Yes, QemuEvent can also be triggered externally - so could at least some of the other synchronization primitives if we had a use case for that. > > Besides, QemuEvent is no different from the existing EventNotifier, I > don't think the churn introduced by the rename is justified. It is as EventNotifiers stood aside our synchronization infrastructure, and were only designed around vhost-net. This moves the concept in the center AND applies it broadly, including to the main loop. That "churn" is adoption to our naming and code organization scheme for synchronization primitives. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux