On Tue, Mar 13, 2018 at 10:07:58AM +0000, Daniel P. Berrangé wrote:
> 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.

Unfortunately it appears you were not CC'd on the reply, but also,
for sake of archives, here is the thread:


This comment is exactly the kind of thing I was concerned about:

 "fd.o#102839 was a bug in code that was already meant to be thread-safe
  since at least 2005, and was previously fixed in 2005, 2006, and twice
  in 2010. I think the fact that we are still finding bugs in the locking
  model in 2018 should tell you something!"

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

libvir-list mailing list

Reply via email to