On Thu, Mar 17, 2011 at 03:19:28PM +0100, Jes Sorensen wrote: > On 03/17/11 11:45, Alon Levy wrote: > > On Thu, Mar 17, 2011 at 11:29:03AM +0100, Jes Sorensen wrote: > >> On 03/17/11 11:27, Alon Levy wrote: > >>> On Thu, Mar 17, 2011 at 10:48:43AM +0100, Jes Sorensen wrote: > >>>>> Same for the asserts below, writes are from spice server thread, reads > >>>>> are in iothread. > >>>> > >>>> But shouldn't this make it try to reconnect? Even if the reconnect > >>>> fails, it shouldn't kill the guest IMHO. > >>> > >>> reconnect? between two threads in the qemu process? why would the write > >>> fail to begin with? this is like saying if I'm failing a kvm ioctl I > >>> should > >>> just retry. > >> > >> Ah ok, I missed that part, somehow I had in my mind it was two different > >> processes, despite you mentioning threads. > >> > >> Still if gfx handling fails, it shouldn't nuke the guest. > > > > ok, try to apply that logic to any other device - network, usb, etc., I > > don't > > think it holds. > > Maybe I am looking at the wrong angle - I would think that is network or > usb breaks, we would still keep running, and for gfx the guest should be > able to keep running even if the monitor is disconnected. > > It's not a big issue so if you feel it is fine as is, I won't object.
I think it could be marginally useful - I mean if someone is running a vm with spice it's for desktop use, and that means graphics is important. of course they could be running a server vm and have it for debugging, but that would be silly. This could hide an actual bug, by not aborting here. Not a major point. I'm also not sure what's the right thing to do - turn on a flag for stopping handling requests? it would just open up a whole set of states we don't handle currently, half-working states. > > Cheers, > Jes >
