Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command

Gerd Hoffmann wrote: It doesn't. When an app enables events, we would start queuing them, but if it didn't consume them in a timely manner (or at all), we would start leaking memory badly. We want to be robust even in the face of poorly written management apps/scripts so we need some expiration function too. There two issues with this syntax. The first is that 'notify EVENT' logically acts on the global event set. That's not necessarily what you want. For instance, libvirt may attach to a monitor and issue a 'wait "vm-state vnc-events"' and I may have some wiz-bang app that wants to connect on another monitor, and issue a 'wait "watchdog-events"'. My super-deluxe app may sit watching for watchdog events to do some sort of fancy RAS stuff or something like that. The 'notify EVENT' model makes this difficult unless you have notify act only on the current monitor session. Monitor "sessions" are ill-defined though b/c of things like tcp:// reconnects so I wouldn't want to do that. The second issue is that there is no clear way to deliminate events other than a new line. If we wanted to send data along with events, we really want to be able to span multiple lines. Especially if we want that data to be in the same format as some of the existing monitor commands. You could get around this by introducing a new deliminator like '.' but everyone can already handle '(qemu)'. That said, I can see a few advantages in the above model. Obviously, the ability to read a large chunk of output and then parse multiple events in a single round trip is a big positive. You could get that with my syntax by sending multiple wait commands at once but that's a bit hackish. Also, I think where the above really shines is if you're a human user and you want to see all the events while debugging. You really don't want to keep typing wait in the monitor. So as a compromise, I think we need to introduce a mode where we can do the above but I'd like to wait until after the first round of these go in. I'm thinking along the lines of 'wait N' where N can be -1 to signify an unlimited number of events or something like that. Good point, I like wait_event personally. Regards, Anthony Liguori -- Regards, Anthony Liguori