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@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Reply via email to