AddMatchWithID / RemoveMatchById

Ryan Lortie desrt at
Tue Feb 19 18:53:43 PST 2008

Thanks for the quick reply.

On Tue, 2008-02-19 at 20:21 -0500, Havoc Pennington wrote:
> Hi,
> Can you elaborate on the client library API this is intended to
> support? In particular it isn't clear to me when I would want to know
> that a signal comes from a match rule, vs. simply what the signal is.
> It seems to me that if I do xyz when FooHappened, the match rule that
> caused me to know that FooHappened should not be relevant.

A simple example:

Imagine the dconf library wants to receive all "notify" signals subject
to some match rule like /apps/foo/.  It can call some function like

g_bus_match ("[rule for /apps/foo/]", my_callback, user_data);

Someone else (in the same application) wants to make legitimate use of
dconf's public DBus API and registers a watch on /apps/bar/.

g_bus_match ("[rule for /apps/bar/]", other_callback, user_data);

As a client library implementation, I see an arriving signal from dconf
for [some path].  Without rerunning the signal matching rules, what
callback do I invoke?  If I receive a match ID then I can match that up
with the ID that I generated for a particular invocation of
g_bus_match() and would then know which callback to invoke.

Note also that this client side library would support delivering a given
signal to more than one user (this is why we have a list of match IDs
instead of just one).  This means that dconf's watch for /apps/foo/ is
completely unaffected by someone else in the same app with a similar

> One quick note, I think one library will always own a given socket
> connected to dbus-daemon; whatever that library is can keep track of
> IDs in use. So adding a round trip to get the ID doesn't seem
> necessary, it's fine if the client lib tracks what's in use. Any code
> module in the app can ask the client lib what ID to use, or am I
> missing something?

You're absolutely right about this.  Whoever owns the open socket can
coordinate assignment of ID numbers for use over that socket.  That
solves the problem without having to wait for a reply from the bus.


More information about the dbus mailing list