matches: treat NameOwnerChanged matches on the driver as subscriptions
Best pracitces for installing a match, is to always match on a sender,
and also install a match on the NameOwnerChanged for the name in case
the sender is a well-known name. That way the subscriber can verify
that any received signal are from the given name (as signals only
contain the unique name of the sender, the association with the
well-known name must be done by each client).
Internally, we are treating a match as a subscription to all signals
from a given name, and iterate through all matches on a given name
for each signal sent from that name, to find the ones that match. This
limits the amount of false negatives to the extent possible, as we do
not know anything about the internal structure of sending clients.
However, when the sending client is the driver itself, we do have more
information, and in particular, the NameOwnerChanged subscriptions are
used extensively (assuming clients follow best-practices), to the extent
that sending out a NameOwnerChanged signal was practically as expensive
as if we had not used a subscription model at all (to a linear factor).
Exploit our knowledge of the semantics of NameOwnerChanged signals, by
associating a match on such a signal with the name that will emmit
the signal. This all but eliminates false negatives when sending out
NameOwnerChanged signals.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Loading
Please register or sign in to comment