| RFC-0007：Zircon 移除线程终止 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 本文档讨论了线程终止功能的移除及其背后的原因。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2020-09-25 |
| 审核日期（年-月-日） | 2020-10-06 |
摘要
过去，zx_task_kill 允许用户模式终止单个线程。不过，
终止单个线程会鼓励不良行为，并且很有可能离开
进程状态不佳因此，终止单个线程的能力
应移除。
动机和问题陈述
用户模式没有合理使用来终止单个线程。公开此类设施 鼓励不良行为。
与其他系统一样，在 Fuchsia 上，线程终止是异步完成的；运行线程的 没有实际的方法可以确定终止线程的确切位置。对于 阻塞（等待）线程时，更安全且通常简单的解决方案是添加逻辑，以便在唤醒 线程会自动退出
终止线程的危险
- 锁可以保持获取状态，包括全局锁，例如控制堆的锁。
- 内存可能会泄露。至少是线程堆栈，但通常有很多其他部分。
- 运行时处于不一致状态。至少对于 C 和 Go 运行时而言是如此。
- 在推进到系统调用的过程中终止线程会使进程处于未知状态。内核是 很好，但是该过程无法得知已发生和未发生的情况。
- 使 RAII 封装容器和自动清理失败。事实上，它击败了 Fuchsia 使用的高级语言。
设计
在将句柄传递给线程时，以下系统调用将失败并显示 ZX_ERR_NOT_SUPPORTED：
zx_status_t zx_task_kill(zx_handle_t handle);
进程和作业仍可照常终止。
实现
幸运的是，在 Fuchsia 中，线程终止的使用率不高。仅有的用例在测试代码中 用于检查线程是否遇到特定异常。我们将更新此代码 例外线程会在异常处理完毕后自行退出。对于 不可恢复，因此，异常线程的指令指针可以直接设置为 zx_thread_exit 或运行时的线程退出函数。这些测试 可能仍然会泄露例外线程在堆上存储的内容， 更好的状态，并在测试流程退出时收集泄漏信息。
性能
不适用
安全注意事项
不适用
隐私注意事项
不适用
测试
将更新 Zircon 核心测试，以确保 zx_task_kill 系统调用按预期运行。 可以进行一定量的静态分析，以查找已传递的 zx_task_kill 的调用点 线程。
将遵循完整的 Fuchsia 大规模变更 (LSC) 流程，以确保此次变更 经过正确测试。
文档
zx_task_kill 的文档将更新为 反映线程不可终止。
缺点、替代方案和未知之处
此提案的替代方案是当前的现状，即允许讨论帖 被杀了。在整个 Fuchsia 历史中，线程一直是可终止的，但还没有 程序依赖于此行为的任何可接受的用例。因此 我们相信可以安全地移除线程终止