AddMatchWithID / RemoveMatchById

[Ryan Lortie]

On Tue, 2008-02-19 at 22:39 -0500, Havoc Pennington wrote:
> Hi,
> 
> 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
> purposes.

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 [0]. I would say if the header would be [0] 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
adjust accordingly.

> 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,
either...

Thanks for the feedback.  It was quite useful.

Cheers