Replacing evil looping code

Havoc Pennington hp at
Mon Nov 6 08:03:21 PST 2006

Bastien Nocera wrote:
> To be fair, we don't really need that "PID" bit, but we'd need one
> instance of the service per instance of our plugin in Mozilla (well,
> pretty much).
> If we can that one-to-one relationship without using a dynamic service
> name, it wouldn't bother me one bit to use it. I didn't see any ways to
> have that using the service route.

Well, each connection does have a unique bus name generated by the bus 
that you can refer to it by. You could easily skip making up your own 
bus name - instead of generating the name with the pid and then 
requesting that name and listening for NameOwnerChanged, just have the 
new process emit a signal like TotemPluginStartedUp, maybe with the PID 
as an argument to the signal, and then from that point forward use the 
unique bus name of the signal emitter.

(I believe this is a little annoying in the glib bindings - the unique 
bus name of the emitter is in the signal message, but not exposed by the 
glib bindings in all cases. Not sure of the details. You could always go 
"low-level" on its ass and add a filter to DBusConnection instead of 
using DBusGProxy.)

This isn't going to help you clean up the code too much, since you will 
still need to block waiting for this TotemPluginStartedUp signal. But 
it's probably more "correct" - anytime you're using a PID to identify a 
bus connection it's kind of conceptually busted (remember the bus isn't 
limited to processes on a single machine, for example)

> As I said, if there was a way to differentiate instances of the same
> service, we'd be in business using the services activation.

I think there may be some confusion here - a service is just a (bus 
name, Exec command) pair, i.e. it means the bus knows how to launch an 
app to own a given bus name. Technically you have no service here - 
there's no .service file - you just have a process that requests a bus name.

Each bus name has only one owner (which is pretty much the whole point 
of bus names).

There is a queue of "waiting owners" but I think no signal when stuff is 
put in the queue. I don't think that queue or a means to query it would 
help you here though, afaics.

To get out of this code you either need some more generic 
block_for_message() feature that blocks (without reentering the main 
loop) for messages matching some criteria, or you need some way to tell 
the bus "I'm expecting something to own bus name XYZ, please block all 
method calls to it as if you had launched something to own XYZ yourself 
based on a .service file"

Either thing would require some API design and thought.


More information about the dbus mailing list