Short lived, or "private", objects on the bus

[Mikkel Kamstrup Erlandsen]

2007/5/21, Havoc Pennington <hp at redhat.com>:
>
> Hi,
>
> Mikkel Kamstrup Erlandsen wrote:
> > Thanks. This is what we will do. I take it the way to do it is the way
> > Ross described by listening for NameOwnerChanged signals (at least it
> > works for me here).
>
> Right, NameOwnerChanged is what you want.
>
> > Allow me to sneak a related question into this thread... We need to
> > scale pretty good with regards to spawning searches. Fx ~50 searches
> > within one second could happen - will dbus be a bottle neck here if we
> > choose to make Search objects real dbus objects (because we need to
> > register each one on the bus)?
> >
> > I assume that spawning a new object takes a round trip to the bus
> atleast...
>
> Nope, object paths are kept in-process inside your app, the bus does not
> keep track of them.


Hmmm, good to know.

The only single functions you can call in libdbus that do a round trip
> are the functions in dbus-bus.h that wrap a remote method call, and the
> DBusConnection methods with _block() in the name. Otherwise, a round
> trip will be something you can see in your code since you'll send a
> request, then later explicitly block for reply. The higher-level
> bindings sometimes make it easier to inadvertently add round trips,
> though.
>
> The only round trip you are requiring here is that if a search result is
> an object, the app has to do:
>   CreateSearch -> search daemon
>   get back search object <- search daemon
>   invoke method on search object -> search daemon
>
> If you want to avoid that round trip, you would need the app to create
> the search object path, instead of having the search daemon do it. For
> example you could specify that the app will randomly generate a short
> string mkstmp()-style and send it to the search daemon, and the search
> daemon will create an object path with that name (or throw an error if
> the name exists already).
>
> Xlib does pretty much exactly this; the X server allocates blocks of
> resource IDs to connected clients, then the clients use those blocks to
> assign their own IDs to resources they create.
>
> This is probably overoptimization in your case, but it is a useful
> strategy to know.


Ok. I don't think we need that optimization, but we haven't really got any
benchmarks yet. Should be easy to test though...

Thanks a bunch for the insight. Cheers,

Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20070521/3a890e22/attachment.htm