On Wed, Mar 14, 2012 at 10:13:19AM -0300, Luiz Capitulino wrote: > On Wed, 14 Mar 2012 10:01:15 +0000 > Stefan Hajnoczi <stefa...@gmail.com> wrote: > > > On Wed, Mar 14, 2012 at 9:51 AM, Gerd Hoffmann <kra...@redhat.com> wrote: > > > Hi, > > > > > >> The most practical first step would be simply sending the ppm over a > > >> socket from ppm_save(). The 'screendump' command today already blocks > > >> so no new badness is being added. There would be no threads or fancy > > >> image encoding. > > > > > > Adding scaling / compression support will add more overhead though, so > > > doing that without offloading screendump to a thread first is a bad idea > > > I think. Or at least have some numbers to see how bad it actually is. > > > > I agree, that's why I suggest sending the ppm over a socket. It > > transports out the image data and QEMU itself doesn't do the > > encoding/scaling. > > Just out of curiosity, are we planning to extend the current screendump > command or add a new one? > > If we just extend the current command, then we'll have to make the > "filename" parameter optional. But this is a compatible change, I think. > > 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<X, not done..), which looks like as big a drawback.
