From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFkiR-0007x3-QL for qemu-devel@nongnu.org; Thu, 05 Apr 2012 07:19:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFkiP-00040A-WE for qemu-devel@nongnu.org; Thu, 05 Apr 2012 07:18:59 -0400 Received: from david.siemens.de ([192.35.17.14]:19204) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFkiP-0003zt-Md for qemu-devel@nongnu.org; Thu, 05 Apr 2012 07:18:57 -0400 Message-ID: <4F7D7F9D.5080805@siemens.com> Date: Thu, 05 Apr 2012 13:18:53 +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> In-Reply-To: <4F7D7D0E.4080309@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:07, Paolo Bonzini wrote: > Il 05/04/2012 12:55, Jan Kiszka ha scritto: >>> BTW you _could_ have a QemuEvent primitive based on Windows manual-reset >>> events. It can be used in some cases as a replacement for condvars, >>> especially when you have multiple producers and a single consumer (MPSC >>> queue is perhaps the easiest lock-free data structure). It can be made >>> very lightweight on Linux using futexes, and would also support timed >>> wait easily on Windows. The API would be more or less like this: >>> >>> void qemu_event_init(QemuEvent *event, bool set); >>> void qemu_event_wait(QemuEvent *event); >>> void qemu_event_timedwait(QemuEvent *event, int ms); >>> void qemu_event_set(QemuEvent *event); >>> void qemu_event_reset(QemuEvent *event); >> >> Yes, qemu_event_wait/timedwait could be added on top later on when we >> have a use case in sight. But mapping futexes wouldn't be compatible >> with eventfd/pipe based signaling. > > 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux