dbus_shutdown: Why do we need it?

[Havoc Pennington]

Hi,

The function exists for two reasons:
  - some people like to call it at the end of main() for memory leak
    detection (and in fact the dbus test suite relies on it for this,
    make check won't pass if anything covered by the tests leaks)
  - some embedded/special-purpose apps like to be able to completely
    unload a library when not in use (these apps are assumed to have
    full control over libdbus usage, not be in some kind of "desktop
    stack" like gnome or kde)

No GNOME or KDE or similar desktop library or plugin should ever call 
dbus_shutdown() for the reasons you mention. Only apps can call it.

> Obviously moving the responsibility of calling dbus_shutdown to the 
> application's main() function is unacceptable. If libdbus-1 requires some 
> kind of shut-down operation, it should register itself such with 
> atexit(3).

There is no requirement to call dbus_shutdown(), so there's no 
responsibility imposed here. However, if the app author _wants_ to 
dbus_shutdown() for whatever reason, the app author is responsible for 
doing so. No library should ever do it (including in an atexit() 
function - those things cause no end of trouble, since they aren't 
reliably called, aren't called in a defined order, and can't be removed).

I would consider it a huge design flaw if a shutdown() were ever 
_required_, since apps can crash or be killed or the machine can shut 
down, and then the shutdown() would not be called. So shutdown() is 
inherently an optional operation that happens only on orderly exit from 
main().

> Not to mention that we no longer have a corresponding "init" function: 
> dbus_thread_init is now (going to be) unnecessary.

Most of what dbus_shutdown() does isn't undoing the explicit init 
(recall my mail that I don't like explicit init), most of it is undoing 
implicit initialization of library-global resources.

Anyway, I think the main reason dbus_shutdown() exists is for dbus's own 
test suite (where it's successfully killed a number of memleaks), but I 
think there's also a fair amount of demand for it among app authors; 
it's a common request for GLib to have such a function.

It might be good to update the docs with some of the above info.

Havoc