Proper use of dbus_connection_send_with_reply & DBusPendingCall

[David Belser]

On Dec 29, 2007 8:55 AM, Havoc Pennington <hp at redhat.com> wrote:

> > 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 -
>
> Each pending call has an array of data slots. When you allocate a data
> slot, you're adding a slot to *all* pending call objects, not just one.
>
> The intended usage is something like:
>
>   int the_slot = -1; // global variable
>
>   // when slot is needed, ensure it exists
>   allocate_data_slot(&the_slot)
>
>   // when slot is no longer needed, decrement its refcount
>   free_data_slot(&the_slot)
>
> If you allocate a slot that isn't -1, it just ups the refcount on it. So
> this makes it OK to allocate the slot in constructor and free it in the
> destructor, since the slot will exist as long as an object is using it.
>
> The point about how the slot is global, is that you're allocating say
> "the C++ proxy slot for all pending call objects," the idea is that each
> pending call will have a C++ proxy. The data slot thing is not intended
> for callback data used in only one situation, or something like that.
> It's intended for language binding proxies basically and that's it.
>
> Havoc
>
>
Thanks, Havoc that's a little clearer now. I guess what I was missing
was that dbus lib is trying to support multiple bindings at the same
time in the same application. I'm so focused my work that I couldn't
see the need for multiple slots.

The C++ bindings are broken, they allocate a new data slot for each
pending call and then up the ref count in the pending call destructor.
This is not surprising as async calls are not completely implemented.