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. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|