From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LrdZ4-0007KI-BC for qemu-devel@nongnu.org; Wed, 08 Apr 2009 15:36:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrdYy-0007JS-54 for qemu-devel@nongnu.org; Wed, 08 Apr 2009 15:36:01 -0400 Received: from [199.232.76.173] (port=37725 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrdYy-0007JP-2g for qemu-devel@nongnu.org; Wed, 08 Apr 2009 15:35:56 -0400 Received: from rv-out-0708.google.com ([209.85.198.249]:43439) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LrdYx-0005TB-Jk for qemu-devel@nongnu.org; Wed, 08 Apr 2009 15:35:55 -0400 Received: by rv-out-0708.google.com with SMTP id l33so217072rvb.22 for ; Wed, 08 Apr 2009 12:35:51 -0700 (PDT) Message-ID: <49DCFC90.8070805@codemonkey.ws> Date: Wed, 08 Apr 2009 14:35:44 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command References: <1239200204-4934-1-git-send-email-aliguori@us.ibm.com> <1239200204-4934-2-git-send-email-aliguori@us.ibm.com> <20090408143335.GS18076@redhat.com> <49DCBCBE.6010102@redhat.com> <49DCE266.9080809@us.ibm.com> <20090408190611.GC10947@shareable.org> In-Reply-To: <20090408190611.GC10947@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: libvir-list@redhat.com, Jan Kiszka , Gerd Hoffmann , Hollis Blanchard Jamie Lokier wrote: > Anthony Liguori wrote: > >> It doesn't. When an app enables events, we would start queuing them, >> but if it didn't consume them in a timely manner (or at all), we would >> start leaking memory badly. >> >> We want to be robust even in the face of poorly written management >> apps/scripts so we need some expiration function too. >> > > What happens when an app stops reading the monitor channel for a > little while, and there's enough monitor output to fill TCP buffers or > terminal buffers? Does it block QEMU? Does QEMU drop arbitrary bytes > from the stream, corrupting the output syntax? > Depends on the type of character device. They all have different properties in this regard. Basically, you're stuck in a losing proposition. Either you drop output, buffer memory indefinitely, or put the application to sleep. Different character devices make different trade offs. > If you send events only to the monitor which requests them, then you > could say that they are sent immediately to that monitor, and if the > app stops reading the monitor, whatever normally happens when it stops > reading happens to these events. > > In other words, no need for arbitrary expiration time. Makes it > determinstic at least. > You're basically saying that if something isn't connected, drop them. If it is connected, do a monitor_printf() such that you're never queuing events. Entirely reasonable and I've considered it. However, I do like the idea though of QEMU queuing events for a certain period of time. Not everyone always has something connected to a monitor. I may notice that my NFS server (which runs in a VM) is not responding, VNC to the system, switch to the monitor, and take a look at the event log. If I can get the past 10 minutes of events, I may see something useful like a host IO failure. >> Monitor "sessions" are ill-defined >> though b/c of things like tcp:// reconnects so I wouldn't want to do that. >> > > Oh dear. Is defining it insurmountable? > > Why can't each TCP (re)connection be a new monitor? > You get a notification on reconnect but not on disconnect. Basically CharDriverState is not designed around a connect model. The fact that it has any notion of reconnect today is really a big hack. CharDriverState could definitely use a rewrite. It hasn't aged well at all. Regards, Anthony Liguori