<div><div dir="auto">I am not sure about what you recommend to do here.</div></div><div dir="auto">This cache is IMO over complicated and it breaks layering.</div><div dir="auto">I’m mostly done in a PR replacing the dlink with a std::list but without changing the overall design. It does kill a few tens of lines of code and is clearer to read tho.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 4 Apr 2020 at 07:41, Amos Jeffries <<a href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 4/04/20 3:34 am, Alex Rousskov wrote:<br>
> On 4/3/20 7:25 AM, Francesco Chemolli wrote:<br>
> <br>
>>   I'm looking at places where to improve things a bit, and I stumbled<br>
>> across cacheMatchAcl . It tries hard to be generic, but it is only ever<br>
>> used in ACLProxyAuth::matchProxyAuth . Would it make sense to just have<br>
>> a specialised cache for proxyauth?<br>
> <br>
> I wonder whether proxy_auth is special in this context:<br>
> <br>
> 1. Is proxy_auth cache radically different from other ACL caches such as<br>
> external ACL cache? Or did we just not bother unifying the code<br>
> supporting these two caches?<br>
> <br>
<br>
Pretty much yes, we have not done the legwork. Almost every component in<br>
Squid which deals with externally provided state has some form of ad-hoc<br>
cache. If we are lucky the use a hash or dlink. One at least uses splay<br>
(ouch).<br>
<br>
<br>
One of my background projects in the effort to empty the PR queue this<br>
year is to implement a proper CLP Map - specifically for PR 30 instead<br>
of the LruMap disagreement blocking it. That would be a good container<br>
to use for all these small state data caches all over Squid - keyed<br>
access with a dual TTL and LFU (fading) removal mechanism.<br>
<br>
If this ACL cache is not causing issues already we can wait until that<br>
gets submitted for review.<br>
<br>
<br>
> 2. Do some other ACLs cache nothing just because we did not have enough<br>
> time to add the corresponding caching support? Or do proxy_auth and<br>
> external ACL poses some unique properties that no other ACL already has<br>
> or likely to have in the foreseeable future?<br>
<br>
The only thing special is that cache they use is exclusively accessed by<br>
them.<br>
<br>
IDENT, ASN, DNS based ACLs also use caches. But those are a bit detached<br>
from the ACL code itself (eg fqdncache) since other code sometimes<br>
accesses the cache directly for other uses.<br>
<br>
<br>
Amos<br>
_______________________________________________<br>
squid-dev mailing list<br>
<a href="mailto:squid-dev@lists.squid-cache.org" target="_blank">squid-dev@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-dev" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-dev</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">@mobile</div>