| RFC-0007：移除 Zircon 終止執行緒 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 本文件說明如何移除執行緒終止功能，以及移除背後的原因。 |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2020-09-25 |
| 審查日期 (年/月) | 2020-10-06 |
摘要
過去，zx_task_kill 允許使用者模式終止個別執行緒。不過，終止個別執行緒有助於採取不當做法，並極有可能使程序處於不良狀態。因此，您應移除終止個別執行緒的功能。
激勵與問題陳述
對使用者模式終止個別執行緒並沒有合理的使用方式。揭露這類設施 會採取不當做法
在 Fuchsia 上，就像其他系統一樣，終止執行緒是以非同步的方式完成。如果是執行執行緒，就無法實際判斷在哪些位置可以安全終止執行緒。針對區塊 (等待中) 的執行緒，較安全且常見的解決方案就是新增邏輯，以便在喚醒執行緒時自行結束。
危險會終止執行緒
- 允許收購智慧門鎖，包括控制堆積的全域鎖。
- 記憶體可能外洩。至少是執行緒堆疊，但通常還有許多其他部分。
- 執行階段處於不一致的狀態。對 C 和 Go 執行階段來說至少是如此。
- 終止執行緒並傳送至 syscall，會導致程序處於未知狀態。核心很有用，但整個流程無法得知發生了什麼事，以及有哪些事發生了。
- 能擊敗 RAII 包裝函式和自動清理。事實上，它擊敗了 Fuchsia 採用的高階語言，絕大多數的保證。
設計
將控制代碼傳遞至執行緒時，下列 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 呼叫網站。
我們將遵循完整的 Fuchsia 大型比例變更 (LSC) 程序，確保這項變更經過妥善測試。
說明文件
zx_task_kill 的說明文件將會更新，以反映執行緒無法終止。
缺點、替代方案和未知
本提案的替代方案為目前狀態，是為了允許終止執行緒。Threads 在整個 Fuchsia 都能夠終止，但目前尚未允許任何程式仰賴此行為的程式使用。因此，我們認為可以安全移除執行緒終止行為。