文档【免费下载链接】rfcsRFCs for changes to Rust项目地址https://gitcode.com/gh_mirrors/rf/rfcs点击查看免费下载std::thread_local是 Rust 1.0 前夕标准库中一个独立的顶层模块而本篇关联文档 text/0909-move-thread-local-to-std-thread.md 提出了一个看似简单却影响深远的重构把它的全部内容并入std::thread彻底删除std::thread_local模块。这篇文章将以该 RFC 为骨架结合仓库内 RFC 0461、RFC 3184、RFC 2788 等后续文档完整还原这次 API 整合的动机、设计细节、权衡取舍以及它最终演化出的LocalKey/thread_local!现代形态帮助读者理解 Rust 标准库在模块组织与 API 稳定性之间的经典决策思路。一、背景一份短小却关键的 API 重组提案RFC 0909 于 2015-02-25 提出正值 Rust 1.0 发布前夕。整份文档非常简短没有大段的语法设计或底层实现核心只做一件事将std::thread_local模块的内容迁移到std::thread中并彻底从标准库中移除std::thread_local。从仓库结构看RFC 按编号保存在 text 目录下0909 之前的 text/0461-tls-overhaul.md 刚刚完成了 TLS线程局部存储模块的整体重设计0909 之后的 text/3184-thread-local-cell-methods.md、text/3642-thread-spawn-hook.md 则持续在thread_local!/LocalKey之上叠加能力。也就是说0909 是 TLS 模块从设计成型走向最终稳定形态之间关键的命名与组织调整。二、历史沿革thread-local 在标准库中的演化路径要理解 0909 的价值需要先看清它之前 TLS 模块经历了什么。仓库中的 text/0461-tls-overhaul.md2014-11-11记录了更早的全局重设计。2.1 std::local_data 时代的缺陷RFC 0461 明确指出早期标准库的答案std::local_data基于旧的 Task 模型1:1 或 M:N 任务设计存在几个致命缺陷见 RFC 0461 的 Current Drawbacks 一节性能不佳一次查找是O(log N)N 是任务已设置的 TLS 键数量远不如基于 OS 的 TLS 或#[thread_local]后者只是指针偏移类型灵活性受限只有static类型能存入 TLS带引用的类型无法短期放入析构语义不明确TLS 析构器与 TLS 本身的交互未规范容易引发难以调试的运行时 panic 或未文档化的泄漏依赖本地 Task运行时移除后std::local_data的实现假设不再成立。2.2 RFC 0461 的重设计std::tls 与 std::tls::scopedRFC 0461 提出三个新模块std::sys::tls平台无关的 OS 级 TLS 绑定仅支持*mut u8的 get/set只能用于 unsafe 代码std::tls拥有型owningTLS支持动态初始化与动态析构类型约束T: staticstd::tls::scoped作用域型 TLS可借入borrow任意类型T的引用一段时间。其中 scoped TLS 的核心 API 由宏与KeyT结构构成见 RFC 0461 的 Scoped TLS 一节/// 声明一个新的 scoped TLS 键static 关键字是必需的 /// 用于强调这里创建的是一个 static 项。没有初始化表达式 /// 因为该键初始不包含任何值。 macro_rules! scoped_tls( (static $name:ident: $t:ty) (/* ... */); (pub static $name:ident: $t:ty) (/* ... */); ) /// 表示一个 scoped TLS 键的结构体。 /// 该结构体不能动态创建只能通过其方法访问。 pub struct KeyT { /* ... */ } implT KeyT { /// 在闭包运行期间将值 t 插入该 scoped TLS 槽位。 /// 返回时恢复之前的 TLS 值如果有。 pub fn setR(static self, t: T, cb: || - R) - R { /* ... */ } /// 取出该 scoped TLS 变量中的值如果有。 pub fn withR(static self, cb: |OptionT| - R) - R { /* ... */ } }拥有型 TLS 则对应tls!宏与KeyT: static通过with闭包惰性初始化见 RFC 0461 的 Owning TLS 一节。RFC 0461 还规范了析构器语义TLS 键在析构器运行期间不可访问、析构后可能不可访问、析构期间的panic!会导致进程 abort 等见 RFC 0461 的 Destructors 一节。正是从这套std::tls/std::tls::scoped设计出发标准库后来演进出独立的std::thread_local模块而 0909 就是针对这个模块的收尾整合。三、RFC 0909 提案核心内容3.1 Summary迁移与彻底移除RFC 0909 的提案目标非常干脆见 text/0909-move-thread-local-to-std-thread.md将std::thread_local的内容整体移入std::thread从标准库中完全移除std::thread_local。注意这里彻底移除而不是保留别名转发意味着这是一次不兼容的 API 调整——在 1.0 尚未冻结时完成这种破坏性变更代价远低于稳定之后。3.2 Motivation动机拆解RFC 给出了四点动机见 Motivation 一节概念相关性thread local 与线程直接相关属于线程模型的一部分减少顶层模块数量合并后标准库少一个顶层模块导航更简单合并相关概念所有线程相关代码集中在一个模块中便于理解和查找文档浏览更友好少一个模块入口文档结构更扁平附带收益有可能轻微减少use语句的数量。这几点本质上都是模块内聚性与命名空间扁平化的工程权衡——把强相关的类型收拢到一起让线程这一概念域在std::thread下完整自洽。3.3 Detailed Design详细设计具体设计包含三个动作见 Detailed design 一节模块迁移std::thread_local的内容移入std::thread::local类型重命名Key重命名为LocalKey作用域展平scoped子模块被展平直接提供ScopedKey等类型不再保留嵌套层级。重命名后用户代码可以这样引用原文示例use std::thread::{LocalKey, Thread};一个值得注意的细节是RFC 的 Summary 写的是移入std::thread而 Detailed design 写的是std::thread::local——原文在两级命名之间略有摇摆。从仓库后续文档看最终落地形态是thread_local!宏与LocalKey类型共存于std::thread命名空间之下例如 text/3184-thread-local-cell-methods.md 中直接声明并使用thread_local!定义的LocalKeyCellT/LocalKeyRefCellT。这说明展平、收起子模块层级的意图最终占了上风。四、权衡与代价DrawbacksRFC 作者对这次变更的风险有清醒认识见 Drawbacks 一节时机太晚提案发生在 1.0 发布周期的尾声任何改动都会挤占紧张的发布准备时间收益有限这是一次自行车棚bikeshedding级别的变更——关于命名和摆放位置的争论其重要性远低于功能本身不一定值得维持两个顶层模块也未尝不可可能不值得在这个时间点折腾用户偏好差异部分用户可能更喜欢更多的顶层模块显式的std::thread_local路径自带语义提示。这段权衡非常有代表性标准库的任何重组都在结构整洁与发布风险之间取舍0909 的作者明确承认这可能不值得——但它最终还是被接受并落地说明模块内聚性的价值在评审中占了上风。五、替代方案子模块 vs 展平AlternativesRFC 记录了被否决的替代路线见 Alternatives 一节最初提案是让thread_local作为std::thread的子模块引入而不是展平。这个方案被否定的理由有两点保持层级扁平团队希望避免嵌套层级过深std::thread::local::...的路径比std::thread::LocalKey更长、更绕模块内容单薄thread_local模块自身内容不多单独保留一个子模块的收益太小不值得为其维持一层命名空间。这个决策直接塑造了今天的 API 形态——LocalKey、ScopedKey这些类型被直接放在std::thread下而不是埋在std::thread::local里。六、遗留问题Unresolved QuestionsRFC 结尾只留下一个未决问题见 Unresolved questions 一节将内容移入std::thread的确切策略尚未确定。这里的策略指迁移的具体执行方式——是一次性重命名并提交还是通过弃用deprecation过渡、如何同步更新文档与编译器内部引用、scoped 部分如何展平等实操细节。这份 RFC 的定位决定了它只负责指明方向把执行细节留给实现阶段。七、后续演进从仓库后续 RFC 看 thread-local API 的最终形态RFC 0909 之后仓库中的多份 RFC 持续在LocalKey/thread_local!之上演进恰好可以反证 0909 整合方向的正确性也展示了这套 API 的现代用法。7.1 LocalKey 的现代用法thread_local! Cell/RefCelltext/3184-thread-local-cell-methods.md2021 年指出几乎所有真实的thread_local!使用场景都涉及Cell或RefCell。其典型形态是thread_local! { static THINGS: RefCellVeci32 RefCell::new(Vec::new()); } fn f() { THINGS.with(|things| things.borrow_mut().push(1)); // ... THINGS.with(|things| { let things things.borrow(); println!({:?}, things); }); }该 RFC 还解释了为什么必须用.with(|x| ..)线程局部值不存在正确的生命周期.with()保证任何借用都会在线程结束前终止。这正是 0909 中LocalKey命名的延续——Key被重命名为LocalKey后成为thread_local!宏生成静态项的类型全仓库后续 RFC 都沿用了这个名称。7.2 LocalKey 的便利方法集为了减少.with(|x| ..)的样板代码RFC 3184 为LocalKeyCellT增加了.set()、.get()、.take()、.replace()见 RFC 3184 的完整方法参考thread_local! { static ID: Cellusize Cell::new(generate_id()); } fn f() { ID.with(|id| id.set(1)); // 第一次会调用 generate_id()但结果被丢弃 // 使用新增的 set 可以直接跳过初始化表达式 ID.set(123); }关键语义是.set()会跳过初始化表达式。RFC 3184 给出了一个极端的例子——初始化表达式直接panic!此时.with()会 panic但ID.set(123)不会thread_local! { static X: Celli32 panic!(!); } // 此时调用 X.get() 会 panic X.set(123); // 但 X.set() 是安全的因为它跳过了初始化器 assert_eq!(X.get(), 123);对于LocalKeyRefCellT则增加.with_ref()和.with_mut()把.with()与.borrow()/.borrow_mut()合二为一见 RFC 3184 的 RefCell 方法参考thread_local! { static THINGS: RefCellVeci32 RefCell::new(Vec::new()); } fn f() { THINGS.with_mut(|v| v.push(1)); let len THINGS.with_ref(|v| v.len()); }7.3 LocalKey::with 的 panic 语义text/2091-inline-semantic.md 中列出了标准库中可能 panic 的函数清单其中明确包含LocalKey::withpanic 条件为TLS 已销毁见 RFC 2091 的函数清单。这与 RFC 0461 时代确立的析构器语义一脉相承TLS 键析构期间或析构之后访问会 panic这是LocalKey::with返回Option之外以 panic 兜底的运行时行为。7.4 ScopedKey 的去向scoped-tls crateRFC 0909 中展平的ScopedKey最终在标准库中并没有长期停留——作用域型 TLS 最终走向了独立 crate。RFC 3184 的 Prior Art 一节明确引用scoped-tlscrate 的ScopedKey结构体并说明其语义是必须先.set()才能使用否则 panic。可以看到0909 中提供ScopedKey的命名规划在外部队列中得到了延续。7.5 #[thread_local] 属性路线text/2788-standard-lazy-types.md 讨论了另一种 TLS 形态——直接使用#[thread_local]属性加Lazy组合见 RFC 2788 相关段落use std::cell::{RefCell, Lazy}; #[thread_local] pub static FOO: LazyRefCellu32 Lazy::new(|| RefCell::new(1));该 RFC 指出一旦#[thread_local]属性稳定Lazy有可能取代std::thread_local!宏见 RFC 2788 的说明。这与 RFC 0461 的设想一致——基于 OS 的 TLS 与#[thread_local]是更底层的构建块thread_local!宏则是其上层的便捷封装。7.6 更多仓库内佐证text/0911-const-fn.md作者在实现const fn时指出std::thread_local::imp::Key的所有字段都是 public 的为了让宏填充且因宏缺少稳定性卫生stability hygiene而被标为 stable见 RFC 0911 相关段落。这揭示了旧std::thread_local模块内部实现依赖全 public 字段 宏填充的构造方式也解释了为何 0909 要把Key重命名为语义更清晰的LocalKey并重新规划模块边界。text/1620-regex-1.0.mdregex 1.0 的依赖列表包含thread_local见 RFC 1620 的 Dependencies 一节——说明 TLS 能力被广泛抽取为独立 crate 使用与标准库thread_local!的模块整合并不冲突两者互为补充。text/3642-thread-spawn-hook.md2024 年的 spawn hook 提案直接构建在thread_local!之上实现继承型 thread local见 RFC 3642 的示例thread_local! { static MY_THREAD_LOCAL: Cellu32 Cell::new(0); } std::thread::add_spawn_hook(|_| { let value MY_THREAD_LOCAL.get(); move || MY_THREAD_LOCAL.set(value) });该 RFC 还解释了 thread local 难以直接继承的根本原因thread local 是惰性初始化的当新线程初始化时父线程可能已经消失没有值可供继承且父线程存活时并发访问会引发竞态见 RFC 3642 的 Motivation 一节。这印证了thread_local!LocalKey作为标准库稳定 API 的持续生命力——0909 的整合为后续二十年2015 至今的 TLS 能力演进提供了干净的地基。八、总结与启示RFC 0909 是一份极简但方法论价值很高的标准库变更提案它展示了一个完整的 API 整合决策闭环明确动机内聚性线程相关概念归并、扁平化减少顶层模块、可用性减少use精确设计迁移位置、重命名规则Key→LocalKey、层级展平scoped→ScopedKey诚实权衡承认 1.0 时机敏感、承认收益是 bikeshedding 级别记录被否方案保留子模块路线的完整论证层级深度、内容单薄遗留问题留白把执行策略交给实现阶段。从仓库后续 RFC 回看这次整合的最终成果——std::thread::LocalKey与thread_local!宏——经受住了近十年的演化考验从Cell/RefCell的便利方法RFC 3184到 spawn hookRFC 3642再到#[thread_local]属性的并行路线RFC 2788全部建立在这份短小 RFC 奠定的模块边界之上。对标准库维护者而言这是一个小改动、大影响、慎权衡的经典案例对使用者而言理解std::thread下LocalKey的来历也就理解了thread_local!为什么会呈现今天这样的形态。如需深入研究可继续阅读仓库内相关文档RFC 0461 的完整 TLS 设计、RFC 3184 的 LocalKey 方法参考、RFC 2788 的 Lazy 类型设计 与 RFC 3642 的 spawn hook 设计。赞分享文档【免费下载链接】rfcsRFCs for changes to Rust项目地址https://gitcode.com/gh_mirrors/rf/rfcs点击查看免费下载相关推荐Rust 标准库 Map-Reduce 实战用 std::thread 并行计算数据块数字总和Rust 标准库 Map Reduce 实战用 std::thread 并行计算数据块数字总和 Rust 凭借标准库开箱即用的线程原语 std::threa文档教程Rust 标准库 IO 体系重构设计RFC 0517std::io 与 std::os 大改深度解析Rust 标准库 IO 体系重构设计RFC 0517std::io 与 std::os 大改深度解析 本文围绕 Rust RFC 0517 text/0文档Rust RFC 0823 深度解读std::hash 模块 API 简化与 Hash/Hasher 设计演进Rust RFC 0823 深度解读std::hash 模块 API 简化与 Hash/Hasher 设计演进 导读 Rust RFC 0823 text/文档上一篇凌晨两点的文档危机KMS 激活工具 KMS_VL_ALL_AIO 让我彻底告别 Windows 和 Office 激活烦恼下一篇免iTunes安装苹果驱动快速指南5分钟解决Windows识别iPhone与USB网络共享创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考