On Thu, Jun 30, 2011 at 12:46:59PM +0200, Gerd Hoffmann wrote: > Hi, > > >>Right - the whole ring assumes that the same side removes. of course we > >>can add an IO for that (two - FREEZE and UNFREEZE). But I think this is > >>the wrong approach. Instead, rendering all the commands, and dropping the > >>wait for the client. Right now if we flush we do actually wait for the > >>client, > >>but I plan to remove this later. (we do this right now for update_area as > >>well and that's much higher frequency). > > >To conclude, we still need to flush the command ring before stop. We > >don't want to change migration. So we still need to change spice server > >api. Gerd? > > Yes, looks like there is no way around that to flush the command rings. > > When we have to change the spice-server api anyway, then we should > support async I/O at libspice-server API level I think. Drop the > qxl async thread, have a way to submit async requests to the worker, > let libspice call us back on completion. > > comments?
My thoughts exactly. Any reason to support the old non async messages if we do this? i.e. do we add _ASYNC versions or just change the meaning of the existing ones? as long as we change the major version of the server (it will be 0.10) I think it isn't problematic, right? The only difference with this approach is that we will have to do the reads from the io thread of qemu, which means a single thread reading for multiple qxl devices, but since it will just be doing very minimal work I don't think it should be a problem (it will just be setting the irq). > > cheers, > Gerd
