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

[Gerd Hoffmann]

On 04/08/09 19:44, Anthony Liguori wrote:
> We want to be robust even in the face of poorly written management
> apps/scripts so we need some expiration function too.

Well, if you want protect against broken apps, then yes, you'll have to 
expire events ...

> 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.

OK, having per-monitor events certainly makes sense.

> 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)'.

Point.

> 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.

Hmm.  Why would you want to use -- say -- "wait 3" ?  It probably will 
be either "loop forever" or "single event" mode in practice.  We might 
also have a "single event, but don't block if there isn't any" mode.

cheers,
   Gerd