[libvirt] [RFC] Events API

Daniel P. Berrange berrange at redhat.com
Tue Sep 23 08:19:28 UTC 2008


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




More information about the libvir-list mailing list