【Rust日報】 2019-05-29：異步await語法最終肯定

時間 2021-08-14

標籤網絡 app 框架機器學習異步 async ide 函數性能學習欄目 Java 简体版

原文原文鏈接

orkhon: 機器學習框架和運行時

#Python #ml網絡

Orkhon是用於機器學習的Rust框架，用於運行/使用用Python編寫的推理/預測代碼，凍結模型和處理未知（unseen）數據。app

orkhon框架

「異步系列文章」Part 2: Async/Await語法以外的挑戰 : 取消（Cancellation）

#async #await機器學習

在這篇文章裏，做者討論了若是在應用中取消正在進行的異步任務，這很是有用，主要是由於對它們的結果再也不有任何興趣，因此繼續操做就會成爲資源佔用。好比在超時範圍內沒有收到響應而且應該將錯誤發送回用戶，則應該取消子操做。異步

先來看看在同步中如何取消任務：async

例如ide

在C＃中，使用CancellationToken類型的變量傳遞給每一個方法，該方法是可取消工做流的一部分。這些方法能夠不時地檢查CancellationToken.IsCancellationRequested，以便發現父任務是否已請求取消。在這種狀況下，子任務能夠提早返回（例如經過拋出異常）。函數

其餘語言是這種方法的變體：性能

Go使用Context結構將取消請求傳播到子任務。在Go中，取消請求經過Channel發出信號，由於它能夠輕鬆地使程序等待取消請求或來自其餘來源的狀態更新。學習

Java利用線程局部中斷狀態。若是一個線程得到.interrupted()，那麼若是不處理異常，某些操做將拋出並強制返回子任務。這能夠被視爲某種線程局部的CancellationToken，它在方法之間沒有明確地傳遞。它具備不能在異步上下文中使用的缺點。

這些行爲具備一組特定的共性:

取消始終只是經過取消請求來完成，它沒法執行，即便請求已發出，子進程也可能運行一段時間。
全部方法均可以觀察是否發生了取消，若是子方法受到影響，而且可以對其作出反應

在async/await異步中如何取消：

Rust以外的語言，和同步取消任務的模式相似：

經過專用參數或隱式任務本地參數請求取消
須要方法來觀察取消狀態。
即便取消後，異步方法也會完成。

好比，C＃ async Tasks經過CancellationToken發出取消信號。許多.NET core框架函數支持此參數以傳播取消請求。Kotlin協程標準庫識別取消請求並容許操做在取消時提早停止。Javascript沒有取消的標準化類型，因爲異步Javascript函數將始終運行完成，所以該機制還須要遵循上述所描述的模式。C++協程可使用cppcoro庫中定義的CancellationToken。

Rust對Cancellation的支持與其餘支持async/await的語言有所不一樣。

只需刪除表示異步操做的Future便可觸發取消
不須要方法來轉發取消請求或取消能力（例如，經過傳遞CancellationToken）
取消是同步的 - 由於drop()是同步的
取消不包括單獨的取消請求並等待操做完成的步驟。只有一個取消/刪除步驟。
取消被強制執行 - 子方法不能忽視或推遲取消

這些特性有優勢也有缺點：

取消任務將變得簡單
主要缺點是底層操做必須支持同步取消，好比處理操做系統底層IO的時候，會比較麻煩。但該文章中也給出了一些解決辦法。

更多內容請查看原文。

Read More
文章列表

異步await語法最終肯定

#await

官方核心成員無船大佬在博客上披露，異步await語法的最終提議是繼續推動後綴關鍵字語法： future.await。另外無船大佬還針對Rust語言設計給出了兩點說明：

Rust語言不多有絕對的狀況出現。除了一些必需要作的事，好比類型系統必須健壯以外，其餘絕大多數的問題都是權衡問題。也就是說，須要權衡不一樣種類的方案，選擇團隊認爲優先的道路。這樣作必然會帶來不少正面或負面的想法，因此咱們須要避免非黑即白的二分思想。
點關鍵字，只是一個方案的草圖，並不帶有某種角度的暗示或保證。它仍然須要走RFC流程。
引入@await語法，也是由於權衡成本的問題，由於引入新的符號會帶來成本。

下一步：

準備在Rust 1.37穩定版中引入async/await的最小穩定化版本， 1.37將於8月中旬發佈，並於7月4日發佈。這不會是async/await功能的結束 - 最小功能將會有不少擴展 - 但對於每一個想要使用Rust進行高性能網絡服務的人來講，這將是一個重要的里程碑。