Short lived, or "private", objects on the bus
hp at redhat.com
Sun May 20 15:42:54 PDT 2007
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.
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.
More information about the dbus