RFC-0007:執行緒終止移除

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

既有技術與參考資料