Rust in Everything
基于 crossbeam-channel 0.5.17

版本差异

主线位置:不在主线上。本卷对着发布提交 2920c984 写,本站的 Cargo.lock 锁的是更早的版本;这一页逐条看中间的 CHANGELOG,判断哪些对本站有影响。依据是各 crate 在 2920c984 的 CHANGELOG.md,以及本站依赖的源码里实际调用了哪些 API(在本站中)。只读源码和 lock,不改本站依赖。

flowchart TB
  c15["channel 0.5.15"] --> c16["0.5.16:#1240、#1250"]
  c16 --> c17["0.5.17:#1295、#1296、#1301、#1321、#1284"]
  c17 --> main["main:#1121(未发布)"]
  d6["deque 0.8.6"] --> d8["0.8.7 #1233;0.8.8 #1308、#1321"]
  q12["queue 0.3.12"] --> q14["0.3.13 #1191;0.3.14 #1321"]
  u21["utils 0.8.21"] --> u23["0.8.22 #1237、#1270、#1195;0.8.23 #1294、#1308"]
crate本站本卷中间的版本
crossbeam-channel0.5.150.5.170.5.16、0.5.17
crossbeam-deque0.8.60.8.80.8.7、0.8.8
crossbeam-epoch0.9.210.9.21相同
crossbeam-queue0.3.12(主 lock 和网关 lock)0.3.140.3.13、0.3.14
crossbeam-utils0.8.21(同上)0.8.230.8.22、0.8.23

本站的构建目标都是 64 位:生产镜像在 rust:1-trixie 里构建 Linux 版,开发机是 aarch64 macOS;wasm 前端里没有 crossbeam。下面凡是「只影响 32 位平台」的条目都据此判断。

crossbeam-channel:0.5.15 → 0.5.17

CHANGELOG 里 0.5.16 两条、0.5.17 五条:

版本条目改了什么对本站
0.5.16#1240select! / select_biased! 宏里的代码对 rust-analyzer 补全更友好无:本站和依赖都不用 select!
0.5.16#1250never() 变成 const fn无:没人用 never
0.5.17#1295(泄漏 SelectedOperation 时的 UB)泄漏 SelectedOperation 后 list channel 的 Drop 不再析构未写入的槽(list)无:触发路径要用 Select 并 mem::forget 它的结果;本站代码和 tantivy、tao、wry、muda、tray-icon、global-hotkey 都不用 Select / select!(常见坑)
0.5.17#1296at() 的接收端在消息已被拿走后,recv 按截止时间返回 Timeout,不再无视截止时间永远阻塞(timers)无:没人用 at / after
0.5.17#1301bounded(cap) 构造时 cap + 1 的下一个 2 的幂溢出改成明确 panic(array)无:tantivy 的容量是常数 10 000 和 1
0.5.17#132132 位平台上有 64 位原子时,array / list 的索引用 64 位无:本站只构建 64 位目标,64 位平台上两者相同
0.5.17#1284MSRV 政策改为支持一年内的 Rust 版本无:本站用最新稳定版构建

有界 channel 接收端走后消息不析构在 0.5.15 和 0.5.17 上相同,升级不改变它;修它的 #1121 只在 main 上,没有进任何发布版。它在本站的影响见上一页 tantivy IndexWriter 的有界 channel。

0.5.15 本身是重要的:0.5.12 到 0.5.14 因为 list 的双重释放全部被 yank,0.5.15(#1187)修复(list)。本站锁的正是修复后的第一个版本。

crossbeam-deque:0.8.6 → 0.8.8

版本条目对本站
0.8.7#1233「Optimize Worker::push, Stealer::steal_batch*, Injector::steal_batch*」只影响性能。rayon-core 1.13.0 用 Worker::push,Injector 只用单个 steal(),不用批量窃取(Steal、Retry 与批量窃取),所以只有 push 那一部分在本站的路径上;本站的 rayon 跑的是 tantivy 的段合并,不在请求的热路径上
0.8.8#1308改善与 ThreadSanitizer 的兼容:只在 crossbeam_sanitize_thread 下生效(怎么验证并发代码);本站不用 TSan 构建
0.8.8#132132 位平台的 64 位索引;同上,无
0.8.8#1284MSRV 政策;无

crossbeam-queue:0.3.12 → 0.3.14

版本条目对本站
0.3.13#1191ArrayQueue / SegQueue 新增 push_mut / pop_mut(ArrayQueue 与 SegQueue);只加 API,sqlx 和 pingora 不用
0.3.14#1321、#1284同上,无

crossbeam-utils:0.8.21 → 0.8.23

版本条目对本站
0.8.22#1237AtomicCell::{as_ptr, into_inner} 变成 const;本站依赖不用 AtomicCell
0.8.22#1270CachePadded 加 repr(C),让布局固定、便于和 T 互转(CachePadded)。dashmap、concurrent-queue 只把它当包装用、通过 Deref 访问,不依赖布局,无影响
0.8.22#1195优化 WaitGroup;本站依赖不用
0.8.23#1294修 ShardedLockWriteGuard 被泄漏时违反 Stacked Borrows;本站依赖不用 ShardedLock
0.8.23#1308、#1284TSan、MSRV;无

小结

  • 中间所有条目对本站都没有行为上的影响:本站依赖用到的 crossbeam API 只有 tantivy 的 bounded / send / recv、rayon 的 deque、sqlx 和 pingora 的 ArrayQueue::push / pop、以及 CachePadded,这些在中间版本里只有 deque 的 push 做了性能优化。
  • 不需要为 crossbeam 单独升级本站的依赖;它们会随 tantivy、rayon、sqlx 的正常升级一起前进。
  • 唯一值得盯的是 main 上的 #1121:发布以后有界 channel 的析构时机会变,对本站的影响见 tantivy IndexWriter 的有界 channel。

💬 关联讨论

发起讨论
加载中...