On 7/28/23 10:51, ma...@web.de wrote:
I did a complete rewrite of my patch to remove all recursive
calls in SplayNode. See GitHub Pull Request #1431.
Thank you! Already reviewed :-).
For our large number of IP addresses and clients (request/s) a different
storage type should indeed be
Hi Alex,
visit and walk should share the same problem, but they don't seem to be
used for acls, except for dumping.
Regardless I did a complete rewrite of my patch to remove all recursive
calls in SplayNode. See GitHub Pull Request #1431.
For our large number of IP addresses and clients
On 27/07/23 04:22, Alex Rousskov wrote:>
* I am curious whether your specific use case (going beyond splay tree
destruction) be better addressed by a different storage type than splay
trees. For example, have you considered whether using a IP
address-friendly hash would be faster for, say, one
On 7/26/23 11:25, ma...@web.de wrote:
I've attached a patch that modifies the destroy method of SplayNode
to avoid recursive calls of destroy in single child nodes by moving
the subtrees of the child to the parent node before destroying the
child non recursively.
Hi Martin,
Thanks a lot
Hi squid community,
we experience segfaults with squid 6.1 (and also older versions) during
"squid -k reconfigure" on several linux systems, caused by a stack overflow.
The circumstances are rather special:
- we have a huge dst ip blacklist (> 300.000 enties)
- this original list is sorted (by
