2007/5/21, Havoc Pennington <<a href="mailto:hp@redhat.com">hp@redhat.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.</blockquote><div> Hmmm, good to know. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.</blockquote><div> Ok. I don't think we need that optimization, but we haven't really got any benchmarks yet. Should be easy to test though... </div> </div>Thanks a bunch for the insight. Cheers, Mikkel