[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-dbus
Subject: Re: DBus Object Paths and Refcounting
From: Havoc Pennington <hp () redhat ! com>
Date: 2007-08-12 17:45:27
Message-ID: 46BF4737.2000007 () redhat ! com
[Download RAW message or body]
Hi,
Ryan Lortie wrote:
> This would be really really cool, but maybe it's just completely
> unimplementable. To be quite honest, I haven't thought too much about
> it :)
>
> Any comments?
>
I have some posts in the archives that wax philosophical about the
reasonable approaches to object lifecycle. (e.g. leases and "keep track
of who is using me" are two)
There are a couple issues with just naively doing refcounting:
- you end up firing tons of messages around to ref/unref
- you get tons of leaks if the refcountee does not track
when refcounter disconnects without unref'ing
In practice I think the best thing might be convenience API for "keep
track of who is using me" - something I proposed in that "gbus" thingy I
posted.
The patterns I think are most common:
- permanent/never-die objects
- app-specific API that involves "registering" a client or context,
which effectively allocates resources, which are freed if the
connection that registered disconnects
(i.e. "track who is using me"). But a "manually unregister"
call is usually available also for clients that want to clean
up but not disconnect.
The second one could be called "alloc/free with the server freeing if
the owner disconnects" - refcounting here could be *in the client
process*, there's no need to put it on the server side since the client
is the only owner/user of the object.
I think it's good for at least lower layers of dbus to be agnostic on
the lifecycle policy, but I think convenience API (which we need much
more of) could offer shortcuts to useful patterns and the spec might
even spell out how to do some of the patterns in a standard way.
Havoc
_______________________________________________
dbus mailing list
dbus@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic