| RFC-0240：非同步作業是在物件上 | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 定義 Zircon 中的非同步作業如何與物件互動及處理作業。 |
| 毛皮變化 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2024-02-06 |
| 審查日期 (年-月-日) | 2024-03-11 |
摘要
這意味著要在 Zircon 核心中執行非同步作業： 核心物件，與註冊這些作業所使用的控制代碼無關。
提振精神
Zircon 定義核心物件的非同步等待作業。我們希望 新增含有連帶效果的非同步作業，例如非同步作業 管道讀取因此，我們必須釐清這些 以及他們與處理站上其他行動的互動，和/或 物件
object_wait_async 是非同步作業的一種例子，作用是產生 通訊埠封包。目前的 API 會嘗試 和針對基礎物件執行作業之間的差異。 名稱可能建議，以及指明作業的控制代碼。
相關人員
Zircon
講師：
FEC 任命的人員，透過 RFC 處理此 RFC 上傳資料集之後，您可以運用 AutoML 自動完成部分資料準備工作
審查者：
- maniscalco@google.com
- cpu@google.com
- abarth@google.com
諮詢：
社交功能：
需求條件
定義非同步核心作業的關係，包括 object_wait_async 和處理如轉移和關閉等互動 控制代碼
設計
總覽
Zircon 中的非同步作業可對物件執行 (非控制)。變更 物件狀態可能會影響這些作業。用於變更以下項目的帳號代碼： 參照物件不會影響非同步作業的行為 當中包含以下特例說明的頻道註冊完成後 非同步作業會持續進行，直到完成、明確取消 物件的所有控點都已關閉非同步取消機制 系統會更新通訊埠的作業，以反映新的語意。
Syscall 變更
object_wait_async：
- 移除以下句子：「如果帳號代碼關閉，相關作業就會執行」 但佇列中的封包不會受到影響。」 從說明文件和備份程式碼開始擷取
註冊完成後，非同步等待機制在物件狀態之前會保持有效 變更與觀測條件相符、明確取消，或 物件的所有控點都已關閉
port_cancel：
- 淘汰
port_cancel並提供port_cancel_key做為替代 使用指定金鑰，取消指定通訊埠上的所有作業。簽名：
zx_port_cancel_key(zx_handle_t port, uint32_t options, uint64_t key)
您還可藉此機會新增 options 參數，port_cancel
成效可大幅降低
另一種做法是更新 port_cancel 的實作方式，以便忽略
source 參數。在實際執行中，已註冊可取消的通訊埠作業
並使用不重複的金鑰為每項作業一般來說，這個鍵代表資料的位址
系統處理作業本身有證據可提出
這項變更應該很安全 (請參閱「回溯相容性」一節)，但
安全地部署這項變更並取回 options
使用相同的名稱使用新的作業名稱即可
，以漸進方式更新程式碼並追蹤舊作業的呼叫端。
object_wait_one 和 object_wait_many，其中包含 handle_close：
- 明確記錄的功能集沒有任何變化。結尾文件 同步等待期間的帳號代碼已淘汰。
這些物件在處理以控制代碼識別的一或多個物件上時，會同步等待。三
用於關閉帳號代碼的文件，會取消目前所有的待處理等待狀態
但這根本是兒童不宜
一個執行緒關閉處理常式，以偵測其他執行緒
object_wait_{one,many} 已解決該帳號代碼。節目競賽
比較「handle_close」和「object_wait_{one,many}」彼此可觀察到
ZX_ERR_CANCELED 或 ZX_ERR_BAD_HANDLE。我們現在提供叫車服務
如要取消這些同步等待作業，請將控制代碼與
物件 (https://fxrev.dev/949517)，或讓程式更方便地等待
，以便同步處理其中控制代碼的存取權
使用者空間因為目前不確定在操作控點中的時機
必須是有效的動作，此提案並不會改變行為。
channel_call 和 channel_call_etc：
- 明確記錄的功能集沒有任何變化。
這些協定提供了隱含說明文件，表示與取消行為相同
ZX_ERR_CANCELED 傳回值中的 object_wait_{one,many}。他們的
和這類運算使用 handle_cancel 時
一般情況下，不過由於這項作業會公開較多的內部詳細資料
可能發生突發的情況，但成交並不容易。
channel_call 的內部等待無法由除了
逾時，因此程式無法使用多種條件來協調關機時間。目的地：
必須提供單獨的作業，例如：
https://fxrev.dev/949517 所提議。與 object_wait_{one,many} 一樣
目前行為懷疑，此 RFC 並不會提議對
這些作業的行為模式
頻道排序
管道在 Fuchsia 系統架構中扮演獨特角色， 核心中有特殊案例邏輯，可驗證管道中的作業 處理常式必須於呼叫程序擁有時才能成功。管道 系統廣泛用於交換資料和功能。 這類檢查旨在維持管道的機密性和完整性 在不同信任層級的程序之間傳遞帳號代碼。 一旦特定程序獲得某個管道的帳號代碼，就會依照承諾 具備專屬存取權，可讀取及寫入該端點的訊息。為了保留這項資訊 屬性，以及此 RFC 中提議語意，且適用於 並使用非同步管道作業 也就是管道端點只有一個帳號代碼轉乘 對管道控制代碼執行的作業可視為對物件進行的操作 我們可能就會在管道發生異動時 移轉失敗。
觀察物件狀態 (例如 READABLE 和 WRITABLE 信號) 不會
違反我們關心的資源如果程式可以觀察到
轉移帳號代碼之後，如果管道可讀取或寫入
因為這項資訊不含功能或重要的機密資訊
關於系統狀態的相關資訊也就是說，
object_wait_async 作業無須針對管道採取不同行為
與這項提案合作未來管道作業，例如非同步讀取
必須考慮與轉移的互動
實作
這項變動對使用者空間有很大的實質影響，是取消
非同步物件等候通訊埠物件。非同步調度器程式庫
必須分配及追蹤可取消作業的專屬鍵，
如果處理常式已處理這些事件，則不再需要追蹤處理常式值
而非使用物件對 port_cancel 的通話將自動翻譯
將第二個參數從控制值變更為 port_cancel_key，以將第二個參數變更為
常值 0。
在核心端，觀察器、通訊埠和物件之間的關係
表現十分巧妙這項變更可簡化作業程序
在取消期間移除控點資料表鎖定的依附元件
程序，以及啟用未來處理邏輯的重構作業。在
短期內，最直觀的導入方法
以空值 Handle 註冊非同步等待，然後執行非同步作業
將已註冊的等待事件標示為已取消並清理作業，藉此等待取消作業
會在觀察器啟動時查詢觀察器狀態
成效
這項變更可減少非同步作業的核心預約數量 和控點鎖頭的壓力可以在某些類型的 載入。目前的 Microbenchmark 雖然簡單，卻沒有什麼變化 原型實作。使用者空間程式庫也可以儲存較少資訊 才能取消已註冊的非同步作業。
人體工學
這需要應用程式追蹤鍵/值，以便取消個別使用者 非同步作業在實際操作的調度器實作中 (除了保留帳號代碼值以外)。
回溯相容性
這會變更 object_wait_async 和
port_cancel，這些異動不會影響到
這些屬性：
- 非同步等待項目是以不重複的金鑰登錄到每次等待
- 等待中物件的控點並非關閉或轉移 已註冊等候中
今日通常都是如此。非同步等待作業通常與
狀態配置，用於處理等待結果和 key
通常是根據這個分配的位址計算
不必與地址空間中的其他值重複，或是可以出現其他形式的專屬地址
或 ID。帳號代碼通常儲存在本身的資料結構中，並關閉
處理程序必須執行某種關閉程序
參照的所有資源
https://fxrev.dev/984701 是忽略 source 參數的原型，
port_cancel。有一個 Zircon 核心測試會刻意重複使用索引鍵。
但樹狀結構中所有其他測試案例都未經修改這表示
對 port_cancel 所做的變更與目前的程式碼相容。
https://fxrev.dev/986494 是一種相關原型，能將整個生命週期分離 已透過觀察器完成已註冊的控點。評估 關閉控制代碼以取消未完成的非同步等待。我們目前的 這項變更表示行為發生變化，但測試沒有經過修改 與目前的程式碼相容
安全性考量
本提案允許程序觀察物件狀態變化， 在某些情況下可能會產生較長的代碼在此模型中，控點代表 可啟動非同步作業我們不會 保證一個控制代碼代表對位於 物件中具有不可重複的控點 (最主要為管道) 的物件。
就多數授予可複製的物件型別，會處理具備 無法處理關於該帳號代碼的其他帳號代碼和作業 除非知道該命令的完整歷史 建立或轉移信任來源這項分析並未改變 明顯的方式，如果我們允許在 轉移的帳號代碼，就像註冊商一樣 保留了重複的帳號代碼
具體而言，我們會授予不固定的帳號代碼 承諾會推出具備管道代碼的專屬程序。允許 管道帳號代碼的前任擁有者來觀察管道首次 因此資料轉移後即可讀取，因此安全性可能不是敏感資訊。我們需要 導入與 僅允許目前的帳號代碼擁有者 才能執行這些作業
測試
系統會用這項工具測試通訊埠和非同步物件行為的變更
Zircon 的核心測試套件。程式庫相容性 - 尤其是在調度工具
透過檢查程式庫及相關測試
例如 1、21、12 歲我們現有的整合套件通過了
(請參閱「回溯相容性」一節)，而我們會監控這些
將變更部署至 object_wait_async 時必須特別小心
說明文件
需要為新的 port_cancel_key 加入系統呼叫說明文件
現有營運和說明文件需要按照
到設計部分
缺點、替代方案和未知
以帳號代碼為基礎的替代語意
替代方法是繼續將非同步作業與 正在啟動帳號代碼 (部分目前的說明文件建議) 並維護 這種關係。這麼做會新增 導致這些新作業變得複雜，並使重構與 將核心的管理邏輯最佳化，同時不太需要執行以下作業： 應用程式邏輯
port_cancel重複使用
因此與其定義新的 port_cancel_key Ssys 呼叫，我們可將
現有 port_cancel 的 source 參數，其中 options 參數為
相同大小如果在過渡期間，我們不支援任何選項，且
也會允許在這個欄位中使用處理常式值。在此轉換期間
我們會找出所有呼叫端，並將呼叫更新為 port_cancel，傳遞 0 值
，而不是他們目前提供的帳號代碼值。結尾
因此會開始強制將 欄位設為 0，
我們就可以開始介紹選項值這種做法會帶來什麼挑戰
但可能不容易發現所有呼叫端更新為新的
語意在罕見的情況下，取消非同步等待後才觸發的情況
因此，port_cancel 的動態分析可能無法找出只在
發生異常錯誤處理或計時。
既有藝術品和參考資料
Zircon handle 解決方案模型 - 2020 年的 RFC 草稿 探索其中幾個問題
zx_handle_cancel - 草擬 RFC 定義機制的草稿 ，可取消處理控制代碼的同步作業，避免解決處理問題 種族。