From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0Aec-0005R3-I5 for qemu-devel@nongnu.org; Wed, 22 Feb 2012 06:46:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S0AeW-0003Vx-WD for qemu-devel@nongnu.org; Wed, 22 Feb 2012 06:46:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0AeW-0003Vq-P3 for qemu-devel@nongnu.org; Wed, 22 Feb 2012 06:46:32 -0500 Message-ID: <4F44D594.8000004@redhat.com> Date: Wed, 22 Feb 2012 12:46:28 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <1329860377-6284-1-git-send-email-alevy@redhat.com> <1329860377-6284-10-git-send-email-alevy@redhat.com> In-Reply-To: <1329860377-6284-10-git-send-email-alevy@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v4 9/9] qxl-render: call ppm_save on bh List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alon Levy Cc: elmarco@redhat.com, yhalperi@redhat.com, qemu-devel@nongnu.org, spice-devel@freedesktop.org On 02/21/12 22:39, Alon Levy wrote: > This changes the behavior of the monitor command. After the previous > patch, there is no longer an option of deadlock with virt-manager, but > ppm_save is called too early, before the update has completed. With this > patch it is called at the correct moment, but that means there is a race > between the monitor command completing and the screendump file being saved. > > The only solution is to use an asynchronous monitor command. For a > previous round of this see: > http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02810.html > > Since that's contentious, I'm suggesting we do something that is almost > correct and doesn't hang, instead of correct and hangs. The screendump > user can inotify on the directory and the file if need be. For casual > monitor usage there is no difference. I still think we should defer that and figure how to fix that properly, either using (internally) async monitor commands via qapi, or using an event. > +typedef struct QXLPPMSaveBHData { > + PCIQXLDevice *qxl; > + QXLCookie *cookie; > +} QXLPPMSaveBHData; Is there a need for a separate struct? I think you can just stick the filename into the QXLCookie struct, then write out screen shots in the update area bottom half, no? cheers, Gerd