How to handle requests that take a long time to complete

Will Thompson will.thompson at
Thu Nov 20 15:04:30 PST 2008

Schmottlach, Glenn wrote:
> I am trying to determine the recommended approach to handle a DBus
> request to a service that takes a “long” time to complete. From the
> client-side (e.g. the DBus service “proxy”) most of the DBus language
> bindings allow the client to either block waiting for a response or
> register a callback function to handle the response asynchronously at
> a later time.
> If I am writing a DBus service, however, I have not run across a
> binding that allows the server side callback to defer handling the
> request to a time beyond the scope of the service callback (e.g.
> beyond the “return” at the end of the callback). For example, suppose
> I provide a service that has a method which query’s a huge database.
> Typically querys may take several seconds and during the time the
> service is waiting on the response from an internal database, I don’t
> want to block the mainloop of the DBus service. In fact, I want to be
> able to handle multiple overlapping requests (or at least queue these
> requests up for later processing). So my server has a DBus method that
> looks like this:
> void getResults(const char* cmd, char** results)
> {
>             // Issue request to the internal DB
>             // Either block (do NOT want to do this), or better yet,
> somehow defer replying to
>             // this request at some point in the future.
>             // I don’t want the binding/wrapper code to immediately
> return a result
>             return;
> }

So in dbus-glib-land, the D-Bus method implementation, as specified as
the first element of the DBusGMethodInfo array in a DBusGObjectInfo
struct which you passed to dbus_g_object_type_install_info() to export
your object on the bus, would look more like:

get_results (MyObject *foo, const char *cmd, DBusGMethodInvocation *context)

and to return you call dbus_g_method_return (context, results). Rather
than calling dbus_g_method_return from get_results, you store it
somewhere, issue your request to the database and return to the
mainloop. The DB library will later call a callback with the results;
from that callback, you can call dbus_g_method_return.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : 

More information about the dbus mailing list