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