說明
Zircon API 為傳送和接收功能並非同步。它需要代表寄件者進行核心緩衝處理資料，直到接收端可以清空資料為止。如果傳送資料的總速率大於資料在長時間內讀取速率的速率，系統也可能超出核心緩衝區，來提供服務 (即使是關鍵任務)。
具體來說，若非同步系統 (在極少數情況下) 傳回「再試一次」錯誤代碼，應用程式處理程式碼幾乎是不準確；這些路徑不易測試且難以正確：尤其是在迴圈中單純處理重試作業，可將非同步服務轉換為同步服務，導致活鎖和死結。
而在針對 Zircon 進行程式設計時，開發人員應假設在健康的系統中以合理的頻率傳送處理序間通訊 (IPC) 訊息，才能順利完成。核心會接著對可緩衝的資料量執行一些限制；達到限制時，則以下系統呼叫的呼叫執行緒中會引發政策例外狀況：
精確限制是每個核心物件的每個執行個體強制執行，而且不會以常數的形式向應用程式揭露，這是為了防止根據這些限製而禁止程式碼，這些限制可以隨產品專屬的考量進一步修改。
應用程式或程式庫不會處理例外狀況，在大多數情況下應採取適當的動作，以便讓例外狀況套用至當機分析服務。
避免 IPC 限制的策略
整體而言，主要策略是讓新增的緩衝區頻率平等新增，並從每組消費和生產端中排除的緩衝區。目前有許多可能的配置方式，例如流程控制、要求/回應、要求到期時間、補充容器 VMO 等。最適合的方法取決於服務性質。