From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7oNX-000590-OU for qemu-devel@nongnu.org; Wed, 14 Mar 2012 09:36:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7oN8-0007Xy-Oa for qemu-devel@nongnu.org; Wed, 14 Mar 2012 09:36:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7oN8-0007XW-Gg for qemu-devel@nongnu.org; Wed, 14 Mar 2012 09:36:10 -0400 Date: Wed, 14 Mar 2012 10:36:10 -0300 From: Luiz Capitulino Message-ID: <20120314103610.2c7dccda@doriath.home> In-Reply-To: <4F609D0C.4000708@redhat.com> References: <00c1eea5-ccb2-4b54-89f8-bdbf00fdc8a4@zmail17.collab.prod.int.phx2.redhat.com> <4F5F48F9.7090501@redhat.com> <4F606A09.2080906@redhat.com> <20120314101319.1a617a74@doriath.home> <20120314131932.GH27659@garlic.redhat.com> <4F609D0C.4000708@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH/RFC 0/7] Screendump to UNIX socket & in PNG format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, =?ISO-8859-1?B?TWFyYy1BbmRy6Q==?= Lureau , Gerd Hoffmann , =?ISO-8859-1?B?TWFyYy1BbmRy6Q==?= Lureau , =?ISO-8859-1?B?TWFyYy1BbmRy6Q==?= Lureau On Wed, 14 Mar 2012 07:28:44 -0600 Eric Blake wrote: > On 03/14/2012 07:19 AM, Alon Levy wrote: > > >> Also, when returning the image via fd, we could offload its writing to > >> a bh. This would give us a poor man's async support, where the biggest > >> drawback would the lack of error detection (can this operation fail anyway?). > >> > > > > It leaves detection of completion up to the user, so inotify / parsing > > the file to see if it's complete (header says size X, but file is still > > Y > Notification on a pipe is easy - the reader gets EOF when the writer > closes the fd, with no need to use inotify. Oh, so I was right, it's a pipe. Alon confused me for a few seconds :-) > The only remaining issue is > whether the writer closes the fd early on error, so that the reader gets > an incomplete file. But then the client can tell after getting EOF > whether the image file is complete (read the header, final file size is > too small), without having to have the intermediate management app > parsing headers during the streaming, although it would be a bonus if > there were a way to tell the management app that an error occurred and > qemu closed the write end early. This is async support. Anything other than that is going to be a hack (which can or can not be accepted).