hp at redhat.com
Wed Sep 13 09:59:41 PDT 2006
Julien PUYDT wrote:
> There are other problems with init functions :
> - what if they're called several times ?
> - what if they're called late ?
> More specifically, if an application loads plugins, and those plugins
> use DBus :
> - what happens if several of them initialize dbus ;
> - what happens if my application already has several threads when those
> plugins kick in ?
> There's also the case of using a library which uses dbus behind your
> back (doesn't avahi do that ?).
Basically my opinion on init functions is:
- if they don't have arguments, they are pointless
since the lib could just self-init as needed
- if they do have arguments, every library and plugin
in the process must agree on those arguments
So for example, if there's an "is_threaded" argument, then as a matter
of policy an application must declare up front that it is going to be
true or false. Even if the app does not itself use dbus, it's simply
logically necessary that all in-process plugins in the same app agree on
this argument, because a global init function can be called only one
time. So even if the app does not init, there has to be an agreement by
specification "plugins for app xyz can/cannot set is_threaded"
For a whole stack like GNOME, then every library and app in the stack
This is painful, but it's unfortunately not incidental to library
design; it's inherent. The arguments to an init function set global
variables/state for the process. Global variables/state break modularity
since they are, well, global.
With GNOME and dbus_g_thread_init() there are two sane approaches I can
1. dbus_g_thread_init is guaranteed to always be called, and gtk or
libgnome or whatever calls it; then the libraries or gnomewide
plugins can rely on it
2. the app can choose to call it or not; no part of the gnome library
stack requires it, but the app may choose to require it for that app
and that app's plugins
In case 2, only the app can use dbus threaded, the library stack cannot.
so e.g. gnome-vfs could not use dbus threaded.
If gnome-vfs wants to use dbus threaded, then GNOME must go with #1, at
least for any app using gnome-vfs.
There is nothing afaik that dbus can do about this; whether to do thread
locking is inherently a global decision. dbus could go ahead and do case
1 in libdbus itself and never give an option, but the idea was to punt
it up to the bindings, basically. And then dbus-glib also punted, but
maybe not for any good reason.
More information about the dbus