C convenience lib (was Re: Is dbus_pending_call_set_notify() thread safe?)

[Thiago Macieira]

Havoc Pennington wrote:
>4)
>
>The DBusConnection API _is_ designed for multiple object system mappings
>to share the connection; that's the purpose of the "object tree" for
>registering what object paths you want to handle, and the return values
>from the callbacks like HANDLED vs. NOT_YET_HANDLED.

I know. I did find out about this API too late, though. I have never 
tested it, so maybe you can answer a few questions:

1) does it handle properly the introspections for objects with sub-nodes 
only (no interfaces)? I.e., object paths that were created only because 
they have children objects, like /org for /org/freedesktop/DBus.

2) how does it insert the sub-nodes XML entries for existing objects? That 
is, suppose I register /foo and /foo/bar. If I get the introspection call 
for /foo, does libdbus-1 insert the <node name="bar"/> into my XML data?

3) does dbus_bus_add_match causes a reference count to go up somewhere? 
(preferrably, in the daemon)

>This has worked fine for me for object mappings like the dbus-glib
>GObject one combined with my lame custom one, a combination I've used
>successfully.
>
>I do think it's a bug if it's impossible to coordinate multiple object
>system mappings on one connection using the available APIs, though if we
>deprecated shared connections it is obviously not a very important bug.

I can't consider it a bug if the solution that libdbus-1 provides -- even 
if there's nothing wrong with it -- doesn't fit my needs. See below.

>I'm tangentially interested in why QtDBus wants to own the message queue
>and object tree rather than coordinate, if the reasons are likely to
>apply to other libs or object system mappings using the connection.

The main reason why it is so is because it evolved like that: when I took 
over the code and started improving it, it was already using the 
message_filter function for handling object calls. And it had its own 
object tree. I don't know why it was done like that by the previous 
maintainers -- maybe an older version of libdbus-1 didn't support 
anything else, maybe the developer didn't know any better.

In any case, the fact that QtDBus took over the entire connection and 
disallowed other people to register objects on it means I could add a few 
optimisations and other tricks that we can't live without now. 

Foremost to my mind comes the local call loop: if the destination of a 
message is the same program, the call is delivered without going through 
the DBusConnection. (If there are no complex types, DBusMessage isn't 
used either, since it's very costly to marshall and demarshall) That can 
only work if I know if an object exists or doesn't exist, plus deliver 
the call.

Next there's the issue of QObject thread affinity. Since Qt 4.3, we've 
allowed registration of objects in any thread. However, QObjects have an 
affinity to one thread (the one they were created on) and may only be 
used from that thread. That means I must switch to the other thread 
before I know if I can handle the call or not. So I need to tell 
libdbus "yes, I handled the call" and then later send an error message if 
it wasn't, in fact, handled.

Maybe it can be made to work with 
dbus_connection_register_{object_path,fallback}. Maybe it can't. I don't 
know now. And, quite frankly, even trying out the idea would mean more 
work tearing up the internals of QtDBus than I am willing to dedicate.

What I could do, instead, is to return NOT_HANDLED for the paths that 
aren't in my object tree, but register the paths that are with a dummy 
VTable. That would allow others to use the same connection and register 
paths on it. That would require, however, proper answers to questions 
above. Local loop calls would deadlock if the destination isn't handled 
by QtDBus, though.

-- 
  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/20070802/46b3edcf/attachment-0001.pgp