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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list