From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40706) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFm7T-0006DE-IS for qemu-devel@nongnu.org; Thu, 05 Apr 2012 08:49:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFm7O-0002bs-PT for qemu-devel@nongnu.org; Thu, 05 Apr 2012 08:48:55 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:36265) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFm7O-0002bT-Gq for qemu-devel@nongnu.org; Thu, 05 Apr 2012 08:48:50 -0400 Received: by pbcuo5 with SMTP id uo5so1665577pbc.4 for ; Thu, 05 Apr 2012 05:48:46 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4F7D94A8.8040107@redhat.com> Date: Thu, 05 Apr 2012 14:48:40 +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> <4F7D8227.4050108@redhat.com> <4F7D8A32.5050401@siemens.com> In-Reply-To: <4F7D8A32.5050401@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 14:04, Jan Kiszka ha scritto: >> 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. But QemuEvent takes away the best name for a useful concept (a cross-platform implementation of Win32 events; you can see that in the RCU patches which were even posted on the list). We already have a perfectly good name for EventNotifiers, and there's no reason to break the history of event-notifier.c. Paolo