dbus_g_thread_init()

[Havoc Pennington]

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 
must agree.

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 
think of:
  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.

Havoc