Daniel Veillard wrote:
On Tue, Sep 23, 2008 at 09:19:28AM +0100, Daniel P. Berrange wrote:
On Mon, Sep 22, 2008 at 10:54:58PM +0200, Daniel Veillard wrote:
On Fri, Sep 19, 2008 at 10:54:39AM +0100, Daniel P. Berrange wrote:
Against a virConnectPtr object I'd expect to be able to register
to get an event upon
- A new domain object coming into existance
- A existing domain object going out of existance
So, you could register a callback, call Rich's virConnectListAllDomains()
once, and then rely on the callbacks from that point onwards to keep
your list of domains up2date. So in case of listening for domains:
Just a remark but unfortunately that scheme forces a race between
the start of the event flow and the return of the list. The way used in
the file monitoring API (FAM which I dislike but at least fixed that problem)
is that when you register you get a flow of initial events allowing
to setup your list of object. Certainly less efficient than single
synchronous call but avoid the race. The user code is also simpler
because you only use the events to maintain your state.
Performance vs. accuracy , the balance is still open for long lived
objects like domains though, but as virtualization gets integrated and
efficient maybe it's better to play safe.
I'm not sure I understand what you mean by the race - if you call the
virConnectListAllDomains() first, and then register for events, then
there is a window where you may have missed some domains starting. If
you register for events first and then call virConnectListAllDomains()
then worst case you see domains that you already know about - you ought
not to miss any events.
The problem is that you cannot order the events w.r.t. the time where
the list was actually made. If you get a foo domain stopped event just
after the virConnectListAllDomains() returns with foo running in it,
you can't tell if the domain was just stopped and restarted before the
list or if the domain is really stopped. Maybe there is another event
of foo being started pending but basically you have some uncertainty
about the state and the event. You have 2 unsynchronized information
flow and no causal dependancies garanteed between the two :-)
Keeping a single flow is the only way I think to garantee you always
have a coherent state representation on the client considering the
kind of API we have.
But the event flow is ordered and complete right? The domain can't stop and restart without both events being generated. In your example, you would know that the domain list is stale with respect to the stopped domain. If the start message is pending, the 'right' decision is still to ignore the domain list entry for the stopped domain. The domain list can only supplement knowledge for domains that have not been seen in the event stream.
Steve
Daniel
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list