Making asynchronous calls
simon.mcvittie at collabora.co.uk
Thu Feb 7 03:47:02 PST 2008
-----BEGIN PGP SIGNED MESSAGE-----
On Thu, 07 Feb 2008 at 09:48:56 +0000, Robert Rawlins wrote:
> For arguments sake, lets say that my service function resolves a web service or something like that, I want to be able to call multiple web services at the same time, and handle their results as they are returned to me, however, I'm not looking to 'queue' the requests, as I don't want a slow resolving service to hang the queue. Is this something that making asynchronous calls will solve for me? or will I need to look into some type of thread implementation as well?
This should be fine, as long as your client and service are both
implemented asynchronously (in the sense that we use that word in
dbus-glib and dbus-python, anyway).
The pattern for asynchronous calls in a client is that you call a
function and pass it a callback, then return to your main loop. When the
reply comes in from the service, the binding will arrange for your
callback to be called by the main loop.
The pattern for asynchronous calls in a service is that your method
implementation is given an object representing the pending call (a
DBusGMethodInvocation in dbus-glib or a pair of callbacks in
dbus-python). You are responsible for arranging for the call to be
completed, somehow. Typically, you'd send off a request to the web
service, arrange for the reply from the web service to cause some other
function to run, save the pending-call object somewhere, then return to
the main loop. When the reply comes in from the web service, you
complete the call by doing something with the pending-call object (call
dbus_g_method_return on the DBusGMethodInvocation in dbus-glib, or call the
callback in dbus-python).
If you want some real-world examples:
telepathy-gabble uses asynchronous calls (with dbus-glib) extensively - we
implement many of the Telepathy D-Bus methods asynchronously, using calls to
the async API of the Loudmouth XMPP library.
Many of the services in the OLPC Sugar platform, including the Presence
Service, implement asynchronous calls with dbus-python.
I believe the pattern used by the Qt and .Net bindings is rather
different, with much more threading, but I could be wrong... I haven't
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the dbus