Re: [libvirt] Re: [PATCH 04/12] Domain Events - rpc changes
On Tue, Oct 21, 2008 at 08:57:51AM -0400, Ben Guthro wrote:
This is very similar to what I had in the original patch,
where on the server side, we just increment/decrement a callback_registered counter,
then keep the list of callbacks/opaque data on the client.
The server would then send one rpc to each connected client, whose job it would be
to multiplex this out to all registered callbacks.
There would still be a "one-for-one" for register/deregister, but
this scheme has the following advantages for efficency:
a.) Fewer RPC calls (less data on the wire - one-to-many for events firing)
b.) Less RPC data passed on register/deregister (no need for cb/user_data)
c.) Code is simpler - no need to invent yet another data structure, and list for tracking
tokens
Daniel - what are your thoughts on this?
This is similar to what I had originally implemented, but I'm not
sure if you objected to this part of it, or not...
The bit I didn't like about the original was the extra logic on the server
side of the impl. If we can keep the explicit register & unregister RPC
calls, and require the client todo all ref-counting & multiplexing, then
I wouldn't mind this approach.
eg, on the client side, on the first 'register' API call, send
the 'register' RPC call. Then just count subsequent 'register'
API calls, and don't bother with the 'register' RPC call. Once
the 'unregister' has been called the matching number of times
it can send the 'unregister' the RPC call.
So the 'remote_internal.c' would have to take care of broadcasting
the single incoming event, to all registered listeners of that
particular client.
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 :|