[Telepathy] Uniqueness of objects

Xavier Claessens xclaesse at gmail.com
Tue Sep 30 22:24:58 PDT 2008

On mar, 2008-09-30 at 22:04 +0100, Simon McVittie wrote:
> On Tue, 30 Sep 2008 at 22:42:16 +0200, Xavier Claessens wrote:
> > It's a bit late so I could be missing something, but what about that:
> > 
> > 1) Change the meaning of HoldHandle to mean refcount++
> > 2) Change the meaning of ReleaseHandle to mean refcount--
> Yeah, I thought of that - distributed refcounting, basically (although
> we wouldn't allow clients to unref a handle more times than they'd
> reffed it, and we'd drop all their refs when they died like the current
> HoldHandle does - otherwise it'd be insane).
> This would mean current clients become leaky, although in practice current
> clients never release handles :-P

We could deprecate those functions and add RefHandle/UnrefHandle.
HoldHandle can still be implemented for compatibility by increasing the
refcount only once if called many times. The spec doesn't say exactly
what happens if ReleaseHandle is called more than once, so I guess we
could just say ReleaseHandle==UnrefHandle.

Like that it's perfectly OK to call HoldHandle 10 times, and then call
UnrefHandle just once.

Of course a process can't unref more than it reffed otherwise
UnrefHandle returns an error. And if a process disappear all its refs
are lost.

I guess there is a race condition if the last UnrefHandle is received
just before a RefHandle. Maybe we could wait X seconds before destroying
an handle when refcount falls to 0, to let a chance to resurrect the
handle... Or we just return an error in RefHandle "Sorry, you are too
late, the handle is already destroyed".

> In general the lifetime of a handle seen in a signal is tied to some
> fairly obvious object, usually a channel, which references the handles
> for as long as it exists.

Right, so forget about 3 and 4, channels just keep one ref its handles.

Xavier Claessens.

More information about the Telepathy mailing list