On Mon, Jan 23, 2017 at 06:27:29AM -0500, Marc-André Lureau wrote: > ----- Original Message ----- > > On Wed, Jan 18, 2017 at 08:03:07PM +0400, Marc-André Lureau wrote: > > > Hi, > > > > CCing Jeff Cody and John Snow, who have been working on generalizing > > Block Job APIs to generic background jobs. There is some overlap > > between async commands and background jobs. > > If you say so :) Did I miss a proposal or a discussion for async qmp commands?
There is no recent mailing list thread, so it's probably best to discuss here: The goal of jobs is to support long-running operations that can be managed via QMP. Jobs can have a more elaborate lifecycle than just start -> finish/cancel (e.g. they can be paused/resumed and may have multiple phases of execution that the client controls). There are QMP APIs to query their state (Are they running? How much "progress" has been made?). A client reconnecting to QEMU can query running jobs. This way a client can resume with a running QEMU process. For commands like saving a screenshot is mostly does not matter, but for commands that modify state it's critical that clients are aware of running commands after reconnect to prevent corruption/interference. This behavior is what I asked about in my previous mail. Jobs are currently only used by the block layer and called "block jobs", but the idea is to generalize this. They use synchronous QMP + events. Jobs are more heavy-weight than async QMP commands, but pause/resume, rate-limiting, progress reporting, robust reconnect, etc are important features. Users want to be aware of long-running operations and have the ability to control them. I suspect that if we transition synchronous QMP commands to async we'll soon have requirements for progress reporting, pause/resume, etc. So is there a set of commands that should be async and others that should be jobs or should everything just be a job?
signature.asc
Description: PGP signature