Sync internal commits 2024-09-06
#75Comparing
upstream/ewang/2024-09-06
(1e0e0bc
) withmain
(fa851d6
)+1%
- Improvements
- 0
- Regressions
- 0
- Untouched
- 2
- New
- 0
- Dropped
- 0
- Ignored
- 0
Benchmarks
Passed
continuum_hash
pingora-ketama/benches/simple.rs::benches::criterion_benchmark::continuum_hash+4%
3.8 µs
3.6 µs
create_continuum
pingora-ketama/benches/simple.rs::benches::criterion_benchmark::create_continuum-3%
1.7 ms
1.7 ms
Commits
Click on a commit to change the comparison rangeBase
main
fa851d6
+1%
change lock status memory ordering, tag spans
This changes the memory ordering for the lock status load to `SeqCst` from
`Relaxed` to eliminate a potential source of panics.
Panics had the frames:
```
pingora_proxy::proxy_cache::<T>::handle_lock_status (proxy_cache.rs:748)
pingora_proxy::proxy_cache::<T>::proxy_cache::{{closure}} (proxy_cache.rs:211)
pingora_proxy::HttpProxy<T>::process_request::{{closure}} (lib.rs:509)
pingora_proxy::HttpProxy<T>::process_new_http::{{closure}} (lib.rs:727)
```
which showed we were checking on the status of the lock, after waiting on it,
and still seeing its status as waiting. The status is returned by value, so this
is not a time-of-check to time-of-use problem, this is an inconsistency in how
the lock status is managed. The change in memory order is mostly for the sake of
this programmer's attempts to understand what is happening.
This also completes a couple of TODOs to limit the wait period as well as tag
the span with the lock status.
1e0e0bc
10 months ago
by gumpt