From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFkt0-0002rE-H5 for qemu-devel@nongnu.org; Thu, 05 Apr 2012 07:29:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFksu-0006oJ-BZ for qemu-devel@nongnu.org; Thu, 05 Apr 2012 07:29:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46381) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFksu-0006o0-3g for qemu-devel@nongnu.org; Thu, 05 Apr 2012 07:29:48 -0400 Message-ID: <4F7D8227.4050108@redhat.com> Date: Thu, 05 Apr 2012 13:29:43 +0200 From: Paolo Bonzini 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> In-Reply-To: <4F7D7F9D.5080805@siemens.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: Jan Kiszka Cc: Kevin Wolf , Anthony Liguori , "qemu-devel@nongnu.org" 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. Besides, QemuEvent is no different from the existing EventNotifier, I don't think the churn introduced by the rename is justified. Paolo