[patch] Fix refcounting and locking in dbus-connection

[John (J5) Palmieri]

On Tue, 2006-09-05 at 19:44 -0400, Havoc Pennington wrote:
> John (J5) Palmieri wrote:
> > Yes.  They are both handled.  Basically shared means I am shared by
> > connection_open and am in the shared_connections hash.  In the case of a
> > bus connection we take another ref so the connection doesn't go away
> > until the bus is done with it also.
> 
> But what happens if the bus.c connection is not shared in the 
> connection.c sense? There is no reason it has to be, since connection.c 
> only shares connections if they have the special "guid" property.

If it is not "shared" it is not put in the hash and reffed but it is
still reffed by the bus.  In the case of the guid connections both the
bus and the hash take a ref.  In fact we could most likely use the guid
as the shared flag instead of having the extra one (though the extra one
is a bit clearer).  I'm not sure if I understand your concern since each
element which holds on to a connection now takes a ref and performs
unrefs independent of each other (though in reality a disconnect will
trigger them both).  Of course there is a "memleak" there which we can
fix by timing out connections which are not in use and disconnecting
them though I don't think it is an issue that needs to be tackled by
1.0.

> As an aside, the guid is way too long; for mugshot we made it a lot 
> shorter using "base53" encoding instead of hex encoding ;-) also 128 
> bits is probably huge overkill.

Is this a before or after 1.0 feature?

-- 
John (J5) Palmieri <johnp at redhat.com>