Proper use of dbus_connection_send_with_reply & DBusPendingCall

David Belser thebelserturner at gmail.com
Thu Dec 27 13:45:17 PST 2007


I'm working with the C++ bindings and trying to get Async method calls
working. Here I've been digging in the archives but I'm still not sure
of the proper use of dbus_connection_send_with_reply and
DBusPendingCalls. One of the messages from Havoc said they shouldn't
be used with threads.

Here is what I think I want to have happen. In some work thread, I use
a proxy object and make a non-blocking remote method call. I use
dbus_pending_call_set_notify to attach a call back to the returned
pending call.

At some future point in time, the response comes in and my dispatch
thread will call the call back with the pending call (that now
includes a reply) and whatever user data I set up with the notify.

As I understand it, in a multi-thread setup there are two (at least) issues:

1 - I will be handling the reply in a different thread than the one
that made the call, this may or may not be that big of an issue
depending on how and what my app is doing.

2 - There is a brief window where the dispatch thread may receive the
reply before I've set the callback notify function.

The other thing that I'm confused about is the
dbus_pending_call_allocate_data_slot &
dbus_pending_call_free_data_slot. The language in the api doc is
confusing -

Particularly:

"The allocated slot is global, i.e. all DBusPendingCall objects will
have a slot with the given integer ID reserved."  (for allocate)

And:

"Existing data stored on existing DBusPendingCall objects will be
freed when the DBusPendingCall is finalized, but may not be retrieved
(and may only be replaced if someone else reallocates the slot)."
(for free)

It's likely that I'm just being dense - I've been looking at code for
most of the day. The C++ bindings have a pending call object that
calls 'dbus_pending_call_allocate_data_slot' in both it's constructor
and destructor (yes allocate_slot), I doubt this is correct.

When I get this sorted out, I'll be contributing patches to dbus-c++

Thanks,

Dave


More information about the dbus mailing list