| RFC-0142：zx_thread_legacy_yield | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 引入专门的收益系统调用。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-11-29 |
| 审核日期（年-月-日） | 2021-10-13 |
摘要
我们提议添加新的系统调用 zx_thread_legacy_yield，这会导致
从而将 CPU 让给其他等待线程。此外，
我们将移除 zx_nanosleep 这一特殊情况，即截止时间为
等于零。系统调用名称中的 legacy 作为指示标志存在
是否提供更合适的机制来实现所期望的
行为
设计初衷
zx_nanosleep 的行为与所有调用期限的处理方式不同，
其他系统调用，也就是说，如果截止时间早于当前时间，则
立即返回。目前，这是一种特殊情况，即为截止时间值指定
则等于 0 表示收益。
此外，无法在运行时确定
被特意设置为零，或是通过计算得到的结果。这会
简化了 zx_nanosleep 的运作方式，从而减少开发者遇到的特殊情况
需要注意的事项截止期限可手动设置为零，
导致线程让出，而由于执行了
下一次唤醒（表示现在继续）。
利益相关方
谁对是否接受此 RFC 有影响？（此部分为可选内容， encouraged.)
教员：
由 FEC 指定通过 RFC 监管此 RFC 的人员 过程。
审核者：
已咨询：
社交化：最初在设计文档中讨论了设计。
设计
此方案包含对 Zircon syscall API 的以下更改：
- 添加了
zx_thread_legacy_yield - 简化
zx_nanosleep
其中，zx_thread_legacy_yield 的定义如下：
/// Yields cpu to another waiting thread.
/// `options`: Reserved for future extension. Must be zero.
/// @blocking
zx_status_t zx_thread_legacy_yield(uint32_t options);
在用户空间应用上调用 zx_thread_legacy_yield 时，
发起调用的线程会获得 CPUoptions 参数可以是
用于稍后引入提示
调用 zx_thread_legacy_yield 时 options 等于零
返回 ZX_OK。
调用 zx_nanosleep 时，如果截止时间晚于
单调时钟，则系统会将调用线程置于休眠状态，直到截止时间
（加上 Slack）另一方面，如果截止期限
值等于或早于单调时钟时间，则会返回
。但是，如果截止时间为零，则会导致发起调用的线程
收益。引入 zx_thread_legacy_yield 后，我们的目标是移除
对零截止时间的特殊处理。
此外，syscalls_zx_nanosleep_zero_duration 内核计数器必须为
移除，同时引入了 syscalls_zx_thread_legacy_yield 计数器。
实现
zx_nanosleep(0) 有 2 个调用点（提供
sched_yield）和树内 7 个调用点。
这涉及将工作拆分为四个 CL。
- 引入了新的系统调用
zx_thread_legacy_yield。 - 将树内用户迁移到
zx_thread_legacy_yield。 - 从树用户中迁出。
- 移除了
zx_nanosleep中的收益过载。
CL (1) 将包括文档、语言绑定更新，CL (4) 将包括 请同时更新文档(1) 和 (2) 可合并为单个 CL， 但将实现与迁移分离似乎是一种更加清晰的途径。
性能
对性能没有已知的影响，只是
zx_nanosleep 路径，因为移除了分支。
向后兼容性
zx_nanosleep(0) 的用户不限于 stem 代码库。
安全注意事项
现有代码和新代码的行为完全相同，
因为 zx_nanosleep(0)（现在）等同于 zx_thread_legacy_yield(0)。
为防止出现任何安全问题，zx_nanosleep 将
保持不变，直到 zx_nanosleep(0) 的所有用例都迁移完毕
发送至 zx_thread_legacy_yield(0)。
隐私注意事项
此方案对隐私权没有任何影响。
测试
zx_thread_legacy_yield 的性质使得很难进行可靠的测试，
在
至少我们可以验证返回代码是否符合预期。
文档
我们将针对 zx_thread_legacy_yield 和
更新 zx_nanosleep 的条目，以移除提及期限为零的情况
是一种特殊情况。
缺点、替代方案和未知问题
最大的缺点和担忧是存在
zx_thread_legacy_yield鼓励繁忙的等待模式，
sched_yield 已提供此机制。这些问题可以缓解
通过适当的文档和最佳做法来解决问题。由于
此系统调用是驱动程序，任何其他用法都应谨慎。
当时考虑的另一种替代方案是，将魔法值更改为
其他名称（例如 INT_MIN）。这确实符合计算的截止期限
同时仍保留一个特殊情况。此替代方案将需要
更新树用户，因此需要
添加新的系统调用最大的缺点是，这样做会导致
zx_nanosleep 的截止时间处理方式与其他操作不同，
处理截止日期，例如 zx_object_wait。
先验技术和参考资料
zx_nanosleep使用 0 作为特殊值，用于表示“yield”。问题 有代码可以有效计算截止期限， 计算 0，在这种情况下，意图不是让出，正好相反： “now”执行下一个语句。如果代码包含
yield，通常表明出现了问题。 不幸的是，在缺少硬件的驱动程序中，这种情况并不少见。 正确的信号模式。