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