| RFC-0007：移除執行緒終止的 Zircon | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 本文說明如何移除執行緒終止功能，以及該移除作業的原因。 |
| 毛皮變化 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2020-09-25 |
| 審查日期 (年-月-日) | 2020-10-06 |
摘要
過去，zx_task_kill 允許使用者模式終止個別執行緒。不過
終止個別執行緒會鼓勵不當做法，因此很有可能離開
以錯誤狀態執行處理程序因此，能夠終止個別執行緒
。
動機與問題陳述
使用者模式不能以合理的方式終止個別執行緒。公開這類設施 鼓勵不當行為
在 Fuchsia 和其他系統一樣，刪除執行緒是以非同步方式完成；瞭解如何執行執行緒 並沒有實際的判斷可以放心終止執行緒的確切位置。換 封鎖 (等待) 執行緒，更安全、通常也很簡單的解決方式，就是在喚醒系統時加入邏輯， 執行緒就會自行結束
終止執行緒的風險
- 可保留鎖定，包括全域鎖定，例如控制堆積的鎖定。
- 記憶體可能外洩。至少將執行緒堆疊，但通常還有許多其他部分。
- 執行階段處於不一致的狀態。對於 C 和 Go 執行階段而言，這至少是正確的。
- 將執行緒終止至 Syscall 後，程序就會從狀態不明。核心為 不過，這項程序無從得知發生了什麼情況，以及實際發生的狀況。
- 擊敗 RAII 包裝函式和自動清理。事實上，相較於最高 執行時也讓她瞭解
設計
將控制代碼傳遞至執行緒時，以下 sys 呼叫將失敗，並顯示 ZX_ERR_NOT_SUPPORTED：
zx_status_t zx_task_kill(zx_handle_t handle);
處理程序和工作仍會照常終止。
實作
幸好，福克西亞沒有太多人使用執行緒終止功能。唯一用途是測試程式碼 檢查執行緒是否到達特定例外狀況。這段程式碼會更新， 處理例外狀況後，例外狀況的執行緒就會自行結束。適用於例外狀況 無法復原，但其餘執行緒的指示指標可直接設為 zx_thread_exit 或執行階段的執行緒結束函式。這些測試 可能還是洩漏在堆積上儲存的例外執行緒，但執行階段 並在測試程序結束時收集流失情形資料。
成效
無
安全性考量
無
隱私權注意事項
無
測試
系統會更新 zircon Core-tests，確保 zx_task_kill syscall 可以正常運作。 可執行一定程度的靜態分析，找出傳遞的 zx_task_kill 呼叫站點 。
為了確保這項異動 妥善測試
說明文件
zx_task_kill 的說明文件將更新為 反映執行緒無法終止。
缺點、替代方案與不明
此提案的替代方案是現行狀態，讓執行緒可以 殺死了。討論串可殺死了她的所有歷史，但至今仍未遭人殺害 任何程式利用這種行為的使用限制。因此 我們認為可以放心移除執行緒終止作業。