hp at redhat.com
Mon Nov 13 23:00:10 PST 2006
Gary Cramblitt wrote:
> If you send many such references,
> you may need a way to "shorten" the names by providing an object reference
> registry and pass integer IDs instead of Path Names. Some projects are
> proposing to use XAtom for this.
This is not a good idea imo,
1) relative to everything else happening the size of the object path is
probably not even measurable as a performance issue - it isn't a large
fraction of the dbus message, and message size does not make a big
performance difference anyway unless you're shoveling megabytes of data
(in which case the megabytes of data presumably are not just object refs)
2) you can use a path like "/abcd" if you like, which is extremely short
(though I'd advise a namespace instead, even say "/com/example/abcd" is
plenty short). Or if you want integer IDs in-process then just track
them and make the object path /com/example/1234 where 1234 = your
3) in real-world performance the X atom will be *much* worse than some
extra bytes in dbus messages; it will mean talking to the X server (even
round trips), and there is no way to delete old unused X atoms.
For performance, the first worry should always be round trips, not size
of messages. Sending and receiving a message involves all sorts of
parsing, validating, context switching, etc.; this fixed overhead is
almost all the work. As long as your message is under 1K or so (whatever
the buffer size libdbus uses, don't remember), the number of read/write
syscalls will be the minimum number. So shrinking the message will do
one thing: *very* slightly speed up the memcpy()'s that happen, which
are not the bottleneck anyway.
> 2. Object lifetime and reference counting. After passing an object reference
> to another process via D-Bus, how do you know when the object may be
> destroyed? Typically, as is done in XPCOM, this is managed via reference
> counting. Trying to do reference counting over D-Bus is challenging.
s/challenging/totally insane/ (been there done that)
What you want to do here is have explicit lifecycle policies on remote
objects. Good ones include:
- stateless. like http, just have calls that don't require keeping
an object around beyond a single request.
- leases. Remote object times out and has to be recreated.
- explicit destroy. Users of a remote object must call a "destroy"
method. (Best combined with a remote object implementation that
tracks when the object owner disappears without destroying, and
automatically cleans up. Otherwise crashed apps cause leaks. dbus
is designed to make this possible.)
A frequent version of the third pattern is a register/unregister kind of
metaphor; to use a given API you must "register" which allocates a set
of resources specific to you and gives you a "registration ID" for
referring to those resources. Many web services APIs, such as the
Facebook one, use a model like this.
You can then either time out registered clients that have not done
anything lately, or you can monitor their presence on the bus and drop
their resources if they vanish.
> 4. Asynchronous versus Synchronous messaging. In all likelihood, you will
> want to implement asynchronous messaging, but when combined with managing
> object lifetime, you'll discover that avoiding race conditions will be
D-Bus should give you the tools to avoid races, though as with anything
asynchronous you have to think about it a little bit. I find it helps a
lot to avoid recycling resource identifiers. So for example unique bus
names won't be reused, so you can know there isn't a race where you'll
suddenly be talking to the wrong process. I would recommend doing
something similar with any custom object paths.
> These are some of the issues you will encounter. If you work out solutions,
> I'd be interested in them, as we have similar issues trying to implement the
> Assistive Technology - Service Provider Interface (AT-SPI), which is
> currently CORBA-based, over D-Bus.
Please post any questions you have and we'll try to help out, btw.
More information about the dbus