[libvirt] [dbus PATCH 16/18] introduce support for libdbus library

[Daniel P. Berrangé]

On Tue, Mar 13, 2018 at 09:39:13AM +0100, Pavel Hrdina wrote:
> On Mon, Mar 12, 2018 at 04:30:30PM +0000, Daniel P. Berrangé wrote:
> > On Mon, Mar 12, 2018 at 05:21:46PM +0100, Pavel Hrdina wrote:
> > > We will switch to libdbus library because the systemd sd-bus
> > > implementation is not thread safe.
> > 
> > Hmmm, libdbus.so isn't all that great with threads either. It has
> > had countless bugs in its thread support over the years to the
> > extent that DBus maintainers have actively discouraged people from
> > using it. GLib didn't even try to use it and wrote new bindings
> > straight to the socket protocol for this reason.
> 
> They still claim it in their documentation that you should use
> different API if possible but if you really want to you can use
> libdbus directly but the only drawback from that claim is that
> the API is low-level and hard to use.

Yes, it is certainly low level - when I wrote the Perl binding I ended
up creating a much higher level wrapper around libdbus to make it
easier to use - similar to how GLib GIO DBus  has the low level and
high level APIs. One deals with messages, the other deals with objects
and methods/properties.

> Another claim from their documentation is that DBusConnection is thread
> safe which is the only thing that libvirt-dbus requires to be thread
> safe, they specifically say that DBusMessage doesn't have any thread
> locks, but that's also OK since the DBusMessage will live only in one
> thread.
> 
> I don't have any experience using libdbus (except this one) so if
> threading is still not reliable and safe then it would be probably
> better to use different API.  I've done some research about libdbus
> before using it and yes, there ware some articles that it was broken
> in the past, however nothing recent.

Yeah, most recent I can find is

https://bugs.freedesktop.org/show_bug.cgi?id=54972

which suggest the core problems were all solved, but the bug is
not marked as fixed so I'm unclear what issues remain.

> > Personally I think it would be worth considering using glib for
> > libvirt-dbus. As well as getting access to a nicer DBus binding,
> > you get to take advantage of higher level APIs that GLib provides
> > compared to STDC / POSIX. The only real downside of using GLib
> > is abort-on-OOM behaviour, but I don't think that's an issue for
> > libvirt-dbus as its just an API shim layer.
> 
> I personally don't like GLib that much, but I can give it a try and
> prepare alternative patches with GLib.

On second glance I'm unclear the recommended way to deal with GLib
DBus APIs when you have long running APIs to invoke. I get the feeling
that you would end up using GTask to spawn single-use threads to execute
the API call, but keeping all dbus interaction in the main thread.
This would likely make it desirable to use the libvirt-gobject library
at the same time to get easier access to async libvirt API execution.

I've copied you on a mail to the DBus mailing list to see if we can get
some guidance from people with more up2date knowledge than me, since
I've not been actively involved in dbus community for a little while now.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|