Dbus method call sent but no reply got

[Yang Chengwei]

On Tue, Sep 17, 2013 at 11:17:56AM +0100, Simon McVittie wrote:
> 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

Yes, I think I didn't speak clearly, in Fei Zheng's case, asynchronous
is invalid, that use dbus_connection_read_write_dispatch() rather than a
mainloop.

As from the dbug log, in dbus_connection_read_write_dispatch() case,
once the dispatch finished, it will poll on soket for read infinitely
and locked io lock, so the later write to socket will always timeout.

> 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.

Good to know.

--
Thanks,
Chengwei

> 
> GLib's GDBus is what I recommend using.
> 
> Regards,
>     S
> 
> [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
>     isn't.
> 
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20130918/94ba6ec7/attachment.pgp>