[Telepathy] Uniqueness of objects
simon.mcvittie at collabora.co.uk
Tue Sep 30 14:04:36 PDT 2008
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
> 3) Each call that return a handle (RequestHandles, GetAllMembers, etc)
> make a refcount++ so the caller is responsible to call ReleaseHandle.
RequestHandles already returns reffed handles.
GetAllMembers etc. shouldn't return reffed handles - the channel internally
references its members already, so clients can't lose (except by losing a race
between inspecting someone and them leaving a channel, but hey).
In heavily extensible APIs (Messages, anyone?) clients can't know what's
a handle and what isn't (imagine we added a
talking-about-this-person-behind-their-back: u key to messages - older
client wouldn't know this was a CONTACT handle, so they wouldn't know to
unref it). So, we *can't* return referenced handles via these APIs.
> 4) Handles spontaneously created and emitted in a signal have a "weak
> ref" that expires after X min if not reffed by HoldHandles (or
> GetMembers, etc). Where X is big enough for a dbus round-trip.
Suddenly every handle repo implementation needs to be hooked into the
main loop? That's fairly terrifying, and there's no correct value for X
(although if your D-Bus round trip takes longer than say a minute,
you've already lost).
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 155 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20080930/951f1cd0/attachment.pgp
More information about the Telepathy