dbus_g_connection_close() ?

[Havoc Pennington]

On Tue, 2005-09-06 at 15:25 -0400, Colin Walters wrote:
> 
> We should probably also fix libdbus to get rid of the idea of refcounts
> for shared connections; e.g. the docs for dbus_connection_open shouldn't
> mention the refcount, and dbus_connection_{ref,unref} should have
> _dbus_return_val_if_fail (!connection->shared, NULL) or whatever.
> 

I think the right way (I'm not sure it currently works this way) is that
the global variable for the shared connection owns a ref. This ref is
tied to whether the connection is connected. So when the connection is
closed or disconnects, the global variable is set to NULL and drops its
refcount.

Users of the shared connection are allowed to add a ref, and remove
their ref, but they can't remove the ref owned by the global shared
variable. You want to be able to ref/unref for e.g. thread safety or
language bindings wrappers, in order to keep the DBusConnection's memory
block valid, even if the connection is closed and the global shared
variable cleared.

In other words the lifecycle of the object for actually using it is an
alloc/free model (like gtk widget new/destroy) but the lifecycle of the
object for keeping it safe to "touch" is refcounted.

Another similar situation is pretty much any Java object that e.g.
closes file descriptors, normally you want that in an explicit call, not
in the finalizer; it's basically a bug if a Java IO stream calls close()
in the finalizer, since someone should have called close() already.

(Java IO streams _do_ call close() in the finalizer just for safety, but
you aren't supposed to take advantage of this, since it can lead to huge
file descriptor leaks and other weird issues)

Havoc