* Markus Armbruster (arm...@redhat.com) wrote: > "Dr. David Alan Gilbert" <dgilb...@redhat.com> writes: > > > * Markus Armbruster (arm...@redhat.com) wrote: > [...] > >> Collecting several users before building infrastructure makes sense when > >> the design of the infrastructure isn't obvious, or when the need for it > >> is in doubt. > >> > >> Neither is the case for running QMP handlers in a coroutine: QMP > >> commands blocking the main loop is without doubt a problem we need to > >> solve, and the way to solve it was obvious enough for Kevin to do it > >> with one user: block_resize. A second one quickly followed: screendump. > >> > >> The only part that's different for HMP, I think, is "need". > >> > >> Is HMP blocking the main loop a problem? > >> > >> If yes, is it serious enough to justify solving it? > > > > I don't mind if HMP blocks for a small time while doing something, but > > not if it can hang if the guest (or something else like it) misbehaves. > > Not if it's something you might need to issue another command to recover > > from. > > The issue isn't HMP being unavailable while a command executes. The > issue is HMP stopping the main loop while a command executes. > > Stopping the main loop not only stops everything running there, it can > also stop other threads when they synchronize with the main loop via the > Big QEMU Lock.
Yep. > The obvious example is a command accessing a remote filesystem. Special > case: NFS with the hard option can hang indefinitely. That I don't worry about too much for HMP; if your host is hosed, fix your host. > screendump does that, and also waits for asynchronous gfx_update() with > qxl devices. Networking again, with a different peer. That I would worry about since that's probably got interactions with the guest and spice, and all the type of things you might be trying to debug or test. > We already decided that QMP commands stopping the main loop is serious. > > To say it's not serious for HMP amounts to "don't do that then, use > QMP". Which may be fair. Not for me to decide, though. It's certainly more important for QMP; you don't want the main lock being held for everyday type of interactions with management layers. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK