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.
http://www.redhat.com/archives/libvir-list/2007-May/msg00083.html
Dan.
--
|=- 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 -=|