| 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 syscall 的行為符合預期。 可以進行一些靜態分析，找出傳遞執行緒的 zx_task_kill 呼叫網站。
我們會遵循完整的 Fuchsia 大規模變更 (LSC) 程序，確保這項變更經過適當測試。
說明文件
zx_task_kill 的說明文件將更新，反映執行緒無法終止。
缺點、替代方案和未知事項
這項提案的替代方案是維持現狀，也就是允許終止執行緒。在 Fuchsia 的整個歷史中，執行緒一直可以終止，但程式依賴此行為的任何可接受用途案例都不存在。因此，我們認為可以安全移除執行緒終止作業。