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: https://lists.freedesktop.org/archives/dbus/2018-March/017425.html 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!" 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
