Dbus method call sent but no reply got

Simon McVittie simon.mcvittie at collabora.co.uk
Tue Sep 17 03:17:56 PDT 2013

On 17/09/13 11:06, Yang Chengwei wrote:
> On Tue, Sep 17, 2013 at 09:50:18AM +0000, Fei Zheng wrote:
>> In the linux Bluetooth stack(bluez), some message handler works 
>> asynchronous, I don't know why it has no such issue.

I suspect it's because BlueZ has an ordinary epoll/poll/select-based
main loop rather than using POSIX signals for this. If you have a
problem to solve, POSIX signals (as in signal()/sigaction()) are
usually the wrong solution.

POSIX signal handlers interrupt whatever else is going on (e.g.
libdbus blocking in read_write_dispatch, with a lock held) and run
code - it's almost as though you had two threads. That's a very
precarious state to run it - even malloc() is quite likely to crash!
That's why it isn't safe to call library functions, and that's
probably also why your code is deadlocking.

More or less the only safe thing to do in a POSIX signal handler is to
call simple syscalls like write() or close() (the well-known "pipe to
self" trick), to which you respond in the main loop.

On 17/09/13 11:06, Yang Chengwei wrote:
> As you know, asynchronous is invalid.

That isn't true. Using D-Bus asynchronously is correct, and indeed,
recommended - but you have to do your asynchronous operations in a
supported way (e.g. with a main loop, or using GLib's GDBus and its
worker thread[1]), not via POSIX signals.

> static GDBusMethodTable adapter_methods[] = { { "GetProperties",
> "",	"a{sv}",get_properties		}, { "SetProperty",	"sv",	"",
> set_property, G_DBUS_METHOD_FLAG_ASYNC},

Confusingly, BlueZ has its own wrapper around libdbus, which uses the
namespace "GDBus*", "G_DBUS_*", "g_dbus_*", but is not the same thing
as GDBus, an object-oriented reimplementation of D-Bus found in GLib.

GLib's GDBus is what I recommend using.


[1] Internally, GLib's GDBus uses a main loop in a worker thread, which
    is OK because, unlike libdbus, it has a well-defined threading
    model. libdbus wasn't thread-safe until recently, and perhaps still

More information about the dbus mailing list