DBus Object Paths and Refcounting

Thiago Macieira thiago at kde.org
Sat Aug 11 10:45:41 PDT 2007


Ryan Lortie wrote:
>Some method call in your app returns an object path "/some/path" in
>response to some call.
>
>The client receives this message and "dereferences" the object by
>performing some method calls against it.
>
>...but in the meantime...
>
>the object has disappeared from your program by whatever means.  Uh oh.

I'd say it depends on the interface contract.

If it says "this object path I'm giving you will be there for you for as 
long as you need it", then it can't disappear.

If it says "this object path points to an object that may disappear, be 
careful", then it can be deleted.

>Just a random idea I had a little while ago that might be a neat feature
>to implement for high-level language bindings:  When sending an object
>path, the receiving application now implicitly owns a reference on that
>object.

See above.

>When sending, the refcount on the native object would be incremented.
>In addition to this, the high-level bindings would keep track of which
>clients own how many references on each object.
>
>There would also have to be some sort of 'org.freedesktop.DBus.Unref'
>call (which checks that a given client doesn't unref too many things).

Hmm... whereas we could have a standardised interface for that kind of 
thing, right now I think it belongs at a higher level (i.e., user code). 
See below.

>If a client randomly leaves the bus, all of its references drop.
>
>Not sure how to handle broadcast messages containing references.

I'd say that no refcounting happens. Anyone wanting to use that would have 
to explicitly call an increase-ref-count function, which can fail.

>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?

It's implementable, but I don't think it belongs in the bindings.

For one thing, it's completely impossible to implement it in QtDBus. It 
owns only a weak reference to the object, so it knows if it was deleted, 
but cannot prevent the deletion from happening.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070811/8f555986/attachment.pgp 


More information about the dbus mailing list