From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MPR8n-0006UK-0i for qemu-devel@nongnu.org; Fri, 10 Jul 2009 21:12:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MPR8i-0006P7-4s for qemu-devel@nongnu.org; Fri, 10 Jul 2009 21:12:36 -0400 Received: from [199.232.76.173] (port=52569 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MPR8h-0006P4-VW for qemu-devel@nongnu.org; Fri, 10 Jul 2009 21:12:31 -0400 Received: from mx20.gnu.org ([199.232.41.8]:57585) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MPR8h-0007dn-Jx for qemu-devel@nongnu.org; Fri, 10 Jul 2009 21:12:31 -0400 Received: from mail2.shareable.org ([80.68.89.115]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MPR8g-00024p-PW for qemu-devel@nongnu.org; Fri, 10 Jul 2009 21:12:30 -0400 Date: Sat, 11 Jul 2009 02:12:28 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands Message-ID: <20090711011228.GK30322@shareable.org> References: <1247065048-15706-3-git-send-email-markmc@redhat.com> <4A54BABD.3040903@redhat.com> <1247069035.3270.82.camel@blaa> <4A54C634.30007@redhat.com> <4A54E0B3.8090305@codemonkey.ws> <4A54E160.9000900@redhat.com> <4A54E3BC.40306@codemonkey.ws> <4A54E64E.8090100@redhat.com> <4A54EA7D.4040602@codemonkey.ws> <4A54F8F2.2080103@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A54F8F2.2080103@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Mark McLoughlin , qemu-devel@nongnu.org Avi Kivity wrote: > >That misses the point though. We process one command at a time in the > >monitor so we only need to buffer one fd at a time. When we start to > >process multiple commands at once in the monitor, we'll do so with > >multiple monitor states and we'll want to have one fd per monitor state. > > Again I'm thinking of the client. If two client threads issue commands > in parallel there'd be >1 fds on the wire. But qemu can consume them > sequentially so I agree queue may hold just a single fd. No, even though QEMU processes commands sequentially. If the client sends "command_1_with_fd" + FD1 "command_2_with_fd" + FD2 and then waits for the results of commands 1 and 2, QEMU calls recvmsg() and will read "command_1_with_fd\r\ncommand_2_with_fd\r\n" + FD1 + FD2 unless QEMU is consuming only one byte at a time from the socket, and dispatching commands as soon as it sees the line terminator. If QEMU reads more than one byte at a time, and the client sends more than one command without waiting for the previous one's result, QEMU needs to buffer more FDs otherwise some will get lost. -- Jamie