| 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 的整個歷史中，執行緒一直是可殺死的，但目前尚未有任何可接受的用例，可讓程式依賴這種行為。因此，我們認為可以安全地移除執行緒終止功能。