On 2024-07-04 04:57, Nishant Sharma wrote:
On 03/07/24 21:27, Alex Rousskov wrote:
On 2024-07-03 09:27, Nishant Sharma wrote:
Is there any change that we need to do in the configure script to
check for the availability of 64 bit atomic lock and use 32 bit lock
if not available?
It is technically possible (perhaps even without ./configure checks),
but it would require adjusting complex shared tree code in the abcense
of comprehensive ready-to-use tests. It is trivial to break that code.
It is difficult to detect bugs. IMO, we should not expose ourselves to
such risks in this case, especially since Squid uses 64-bit atomics in
many other places: Supporting 32 bits in shared binary tree nodes is
not going to remove the last frequently used 64-bit lock.
Just being curious here, if a certain platform (mips32 in this case) is
unable to guarantee a 64 bit atomic lock, other functions except SMP
mode might get affected as well?
The answer depends on where one draws "SMP mode" boundaries: The locks
in question should have no effect on non-SMP Squid (i.e. Squids with
only one worker process, no cache_dir diskers, and memory_cache_shared
not turned on). Beyond that, it is very difficult to isolate "other
functions" from "SMP mode" because a lot of Squid "functions" ought to
be (and are becoming) SMP-aware and, hence, use shared memory locking.
Disclaimer: I do not know what "lock ID" is in this context.
"lock ID" term was used on Openwrt issue tracker where it was suggested
that "The assertion assumes 64bit lock id.". [1]
Yes, I am aware. I wrote the disclaimer _after_ reading that thread :-).
Let me experiment with squid-6.x on these devices and also use them in
the live environment.
The only change being commenting out the following line from
ipc/mem/PageStack.c:
`assertion(StoredNode().is_lock_free());`
I will report back with success or any failures encountered.
Thank you,
Alex.
[1]
"https://github.com/openwrt/packages/issues/24469#issuecomment-2202322703";
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
