AddMatchWithID / RemoveMatchById
desrt at desrt.ca
Tue Feb 19 20:23:37 PST 2008
On Tue, 2008-02-19 at 22:39 -0500, Havoc Pennington wrote:
> On Feb 19, 2008 9:53 PM, Ryan Lortie <desrt at desrt.ca> wrote:
> > 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);
> Ah OK, I see what I was missing - the dconf path use case.
> I guess the optional-ness of this API means a more traditional
> signal-like use case would not take any performance hit here. (Of
> course, the current dbus-daemon implementation of match rules is just
> a linear list walk anyway, but I'm thinking the ID thing makes a
> better implementation more difficult. If only some match rules that
> really care about the match ID use the match ID, though, then we're
> only (hypothetically) limiting performance when it's useful to do so.)
We keep talking about this but nobody ever seems to do it... :)
In any case, any implementation that allows for a fast way to determine
"yes, this is matched" probably can replace that "yes" with a pointer to
a list of IDs for which the match is valid.
> Something to include in the spec patch is what happens if you try to
> remove a match ID rule "by value" - I would suggest it just doesn't
> work. i.e. that the ID is effectively part of the "value" so two match
> rules, one with and one without ID, do not compare equal for removal
Yes. That's my intention. If you add with ID then the only way to
remove is by using the same ID.
> I like your idea that 0 means default-sent and that if the header is
> missing that means . I would say if the header would be  then we
> should always leave it out, save some bytes. I don't think  should
> be allowed - does not seem useful to me to know that "this message was
> matched by some AddMatch rule" - don't know.
I'm not thinking about this too much right now. It's a very tiny detail
and can be fine-tuned after I've played a bit more with this.
> uint32 with 0 having a special meaning already means there's no
> "invalid" value, which could be annoying when coding things, don't
> know. Perhaps 0 is invalid and 1 means "default sent"?
I think having 0 as 'default sent' is fine since the only places you'll
be writing down match IDs in a data structure won't possibly be confused
with the default sent case. I can see if this becomes a problem and
> The bus daemon will need to enforce that the header is only set by the
> daemon (i.e. that one client can't make up a match id header and send
> it to another client). This is already done for the sender field I
> think, so there's example code.
Yup. This is already mentioned in my changes to the spec.
> Perhaps the daemon just doesn't care about duplicate match IDs - a
> client that does this is creating problems for itself but maybe not
> for the daemon or anyone else... if you re-used a match ID, the daemon
> would just require you to remove it twice, and the rules would be
> removed in undefined order. No client would do that on purpose, of
> course. I'm just wondering if it's worth an O(n) search on adding each
> rule just to throw an exception that should never happen (or worth
> keeping a hash of all ids in use, alternatively - either way, extra
> code just to catch a should-not-happen).
Absolutely agree. This might be slightly murky conceptually but it's
absolutely perfect from a practical standpoint and is much better than
anything I had thought of. It's not even that bad conceptually,
Thanks for the feedback. It was quite useful.
More information about the dbus