[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Re: Asynchronous notifications of domain start/stop

On Wed, Jul 18, 2007 at 12:57:37PM +0100, Richard W.M. Jones wrote:
> >>We would also need to avoid mixing ordinary request/response with the
> >> notifications
> >
> >Why?  Just disallowing notifications while a request is in flight should
> >be enougth I think.
> >
> >I'd like to have something which integrates nicely with the usual
> >select() based event loops, like the xenstore model.  Sort of "here is a
> >file handle, and if data comes in call this function."  The function in
> >turn could either call callbacks or return some event struct.
> I can see this working.
> In the Xen (local) case we can hand back the Xenstore fd itself for 
> applications to monitor.
> In the Xen remote case the server side has already got an event loop 
> which can look for fd events.  They'll be sent synchronously to the 
> client.  The client will have to hand out the remote connection fd for 
> applications to select() on.
> In the qemu case I'm not sure how to modify qemu_driver.c to handle 
> this.  One for Dan Berrange to comment on.

We should not explicitly expose 'the xenstore filehandle', or 'the libvirtd'
filehandle per-se. Instead we should provide an API which lets application
register callbacks for adding/removing file handles to an event loop.

We in fact already have this - look at the src/event.h file. So if we make
this part of the official public API, then applications merely need provide
an impl of the virEventAddHandleFunc and virEventRemoveHandleFunc. The 
underlying libvirt drivers can thus invoke these callbacks as required,
be it with the XenStored filehandle, a XenAPI filehandle, a libvirtd fd
or something else. 

We can provide sample impls of the virEventAddHandleFunc and 
virEventRemoveHandleFunc  code for  GLib and/or QT in a libvirtglib.so
and libvirtqt.so  add-on libraries. This allows for easy integration
with most GUI apps, while also allowing integration with custom home
brew event loops.  This is how DBus provides event loop integration
without tieing itself to a specific impl & it works very nicely.

I outline this previously in the bottom half of this mail.


|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]