Replacing evil looping code
hp at redhat.com
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
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