Hi, > > This is not meant for some long-running job which you have to manage. > > > > Allowing commands being asynchronous makes sense for things which (a) > > typically don't take long, and (b) don't need any management. > > > > So, if the connection goes down the job is simply canceled, and after > > reconnecting the management can simply send the same command again. > > Is this worth its own infrastructure? > > Would you hazard a guess on how many commands can take long enough to > demand a conversion to asynchronous, yet not need any management?
Required: screendump with qxl (needs round-drop to spice-server display thread for fully up-to-date screen content, due to lazy rendering). Nice to have: Move anything which needs more than a milisecond to a thread or coroutine, so we avoid monitor commands causing guest-visible latency spikes due to holding the big qemu lock for too long. From a quick scan through monitor help hot candidates are screendump and pmemsave because they might write rather large data files. Dunno about savevm/loadvm. I think they stop the guest anyway. So moving them to async probably doesn't buy us much, at least from a latency point of view. cheers, Gerd
