From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4btg-0002MQ-AR for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:40:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4btE-0003YX-6X for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:40:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54546) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4btD-0003Wd-V1 for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:40:04 -0500 Message-ID: <4F54FA6D.2010100@redhat.com> Date: Mon, 05 Mar 2012 19:39:57 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1330936455-23802-1-git-send-email-pbonzini@redhat.com> <4F548263.1070905@siemens.com> <4F54CC8A.5010509@redhat.com> <4F54CE10.4040407@siemens.com> In-Reply-To: <4F54CE10.4040407@siemens.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH] fix select(2) race between main_loop_wait and qemu_aio_wait List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "anthony@codemonkey.ws" , Paolo Bonzini , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "laurent@vivier.eu" On 03/05/2012 04:30 PM, Jan Kiszka wrote: > On 2012-03-05 15:24, Avi Kivity wrote: > >> Long-term, I'd like to cut out certain file descriptors from the main > >> loop and process them completely in separate threads (for separate > >> locking, prioritization etc.). Dunno how NBD works, but maybe it should > >> be reworked like this already. > > > > Ideally qemu_set_fd_handler2() should be made thread local, and each > > device thread would run a copy of the main loop, just working on > > different data. > > qemu_set_fd_handler2 may not only be called over an iothread. Rather, we > need an object and associated lock that is related to the io-path (i.e. > frontend device + backend driver). That object has to be passed to > services like qemu_set_fd_handler2. Not sure I like implicit lock-taking. In particular, how does it interact with unregistering an fd_handler? -- error compiling committee.c: too many arguments to function