Is dbus_pending_call_set_notify() thread safe?

[Fan Wu]

Thanks for the response!

It would be nice to document the intention that set_notify() is not
threads. But many developers don't read documents so an even better
idea would be deprecate the function altogether and let other API like
send_and_reply_notify() handle this.

I understand your concern of convenience API. But I think right now
there is market for easy to use, lightweight C bindings of libdbus.
Reasons being that feature-rich bindings like that of Qt and Glib are
normally bundled with their infrastructure, so you can not use QtDbus
without the core libs of QT. Plus the license and size issues, while I
am lazy and is desperate for something off-the-shelf, I have to dig
into the native API for a solution. dbus-c++ is also in my radar, but
it lacks the feature in Qt that a blocking poll/select can be waken
up. My personal take is to have some more convince functions, and have
them built into separate libraries or built into libdbus in customized
builds.

Thanks again,
Fan

On 7/31/07, Havoc Pennington <hp at redhat.com> wrote:
> Hi,
>
> Fan Wu wrote:
> > I have a question for the following code:
> >
> >   dbus_connection_send_with_reply();
> >   dbus_pending_call_set_notify();
> >
> > My understanding is dbus_connection_send_with_reply() will not only
> > add the message to the queue but actually tries to send it. If there
> > is a dispatcher running in another thread and the reply  comes back
> > and is handled before dbus_pending_call_set_notify() is run, my
> > callback will never be called.
> > If this is a valid issue I suggest the two functions above be merged
> > into one so that the callback is set when the pending call is created.
>
> I would guess few people encounter this since set_notify() is usually
> used as an alternative to threads, rather than in conjunction with
> threads. With threads you can just send_with_reply_and_block() perhaps.
>
> That aside, I believe what should work is to set your notify, then call
> dbus_pending_call_steal_reply(). If the reply arrived before you set the
> notify, then it will be returned from steal_reply().
>
> That is sort of inconvenient and unintuitive, I know.
>
> Perhaps we could add a send_with_reply_notify() that takes the notify
> func/data/free_data_func and manages the pending call object for you.
>
> However, libdbus generally avoids convenience API and I'm not sure we
> need send_with_reply_notify() for the benefit of bindings...
>
> Havoc
>
>