dbus_g_connection_close() ?

[Mark McLoughlin]

Hi,

On Wed, 2005-09-07 at 18:54 +0100, Mark McLoughlin wrote:
> On Tue, 2005-09-06 at 20:18 -0400, Havoc Pennington wrote:
> > 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.
> 
> 	Okay, that sounds reasonable. Here's an attempt at that which does it
> in a pretty wacky way - the pre-allocated "disconnected" message holds a
> ref on the connection so that we can safely dispatch the disconnected
> message after removing it from shared_connections even when no users of
> the connection currently hold a ref.

	After looking at this some more I couldn't get away from the fact that
requiring people to close() the connection before the last unref() was
really, really annoying. And my patch was making it even more annoying
because you had to actually handle the Disconnected message or the
connection wouldn't get finalized.

	So, why do we have this requirement? I think its because we want to
guarantee that people will always get a Disconnected message, but if the
app drops the last ref to the connection, why would it want a
Disconnected message? It seems to me that the Disconnected message is
really only useful if the other side of the connection is the one that
closed it.

	Also, you mentioned the thing about Java objects that close file
descriptors doing so in an explicit close() method rather than in the
finalizer ... isn't that because the object isn't garbage collected
until some indefinite time later? We don't have that problem in C ...

	I've hacked up a patch to allow closing the connection when finalizing,
but there's a couple of things to note:

  + The @todo and a _dbus_assert_not_reached() in unref_unlocked() 
    basically comes down to the problem - how can you unlock a 
    connection *after* you drop its last reference, so the function
    doesn't really seem to make sense to me. It came up because
    various things in last_unref() require us to not be holding
    the lock.

  + The ugly hack in unref() is needed because remove_watch() requires 
    the lock to be held and that's called when closing the transport.

	Both need to be fixed properly, though.

	Also, I've attached another patch with some random fixes which are more
obvious.

Cheers,
Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbus-no-more-close-before-last-unref.patch
Type: text/x-patch
Size: 21614 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050910/800aca43/dbus-no-more-close-before-last-unref-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbus-random-fixes.patch
Type: text/x-patch
Size: 6805 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050910/800aca43/dbus-random-fixes-0001.bin