From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============2341528529803788522==" MIME-Version: 1.0 From: Denis Kenzior Subject: Re: [PATCH 13/15] dbus: Add message filter public API. Date: Sat, 26 Mar 2016 16:53:47 -0500 Message-ID: <56F704EB.5070402@gmail.com> In-Reply-To: List-Id: To: ell@lists.01.org --===============2341528529803788522== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Andrew, On 03/26/2016 10:22 AM, Andrzej Zaborowski wrote: > On 26 March 2016 at 03:42, Denis Kenzior wrote: >> Hi Andrew, >> >> On 03/25/2016 06:45 PM, Andrzej Zaborowski wrote: >>> >>> Hi Denis, >>> >>> On 24 March 2016 at 19:04, Denis Kenzior wrote: >>>> >>>> Does it make sense to make glob-match values part of the tree? >>>> >>>> For example, I can install watch 1 with: >>>> type=3D'signal', path=3D'/' >>>> >>>> and watch 2 with: >>>> type=3D'signal', sender=3D'org.foo', path=3D'/' >>>> >>>> Right now it seems we will generate 2 AddMatch cases for the above, ev= en >>>> though watch 2 is already covered by watch 1. >>> >>> >>> Ah, good point. I think we could handle that also with the current >>> structure if we allow the nodes to be added to the tree in any order >>> necessary, so that the "sender=3D'org.foo'" could be a child of >>> "path=3D'/'" in specific cases. This wouldn't add any cost to the >>> filtering of incoming signals, only to adding new rules, what do you >>> think? >>> >> >> Could work, but my first thought is that it would cause lots of addition= al >> processing, since you'd be trying all possible permutations. Given that= we >> have 4-5 rules on average that's a lot of possibilities to try. Or were= you >> thinking something else? > > There would be some additional processing but I think it may be okay. > Now when adding a new rule and we're at a specific node in the tree > we're checking if there's already a child that matches the next > condition in the rule. Instead we could check if there's a match for > any of the yet unused conditions in the rule, and mark that condition > as used or "visited". In the typical case where most rules begin with > a sender value this wouldn't add any overhead I think. > Lets give it a shot. I ran some mental exercises and can't seem to find = any negatives to the idea besides increasing the add filter cost by a = factor of n, where n =3D number of rules being added. The upside is that we could also get rid of the qsort this way. The = silent side-effecting of the input rules is less than ideal. Regards, -Denis --===============2341528529803788522==--