A bit of a warning to those who use D-Bus and GNOME-VFS in the same app. Since GNOME-VFS uses threads and has now switched to using D-Bus it is prudent to initalize threading as early as possible to avoid D-Bus threading being intialized after a connection is established. If such a thing should happen asserts would cause the application to crash as the already created connection would have a dummy mutex while the global mutex lock would be a glib mutex. Initalizing threading early using dbus_g_threads_init() (or dbus.glib.threads_init() in python) avoids this issue by making sure the global mutex is set before any connection is created no matter what your libraries do.
[read this post in: ar de es fr it ja ko pt ru zh-CN ]August 4, 2006
3 Comments
RSS feed for comments on this post.
Sorry, the comment form is closed at this time.
Shouldn’t that be done in an .init section of the dbus library ?
Comment by glandium — August 5, 2006 @ 2:35 am
It can’t be done automaticly in the base library (bindings may be able to do it). This is because the mutex used is dependent on the enviornment you are running in. In GLib you would use the GLib mutex, in Qt the Qt mutex, etc. Also turning on locks when you don’t need them creates a slight performance hit.
Comment by J5 — August 5, 2006 @ 8:03 pm
I should note that GNOME-VFS most likely already does the initalization for you. The problem mostly revolves around application that lazy load it (like some gstreamer plugins). If it is loaded after you start using D-Bus nasty things happen. So it is always prudent to intialize threads early if there is any chance threads will be used in your process space even if it is dynamicly loaded such as with plugins.
Comment by J5 — August 6, 2006 @ 12:47 am