本頁面由 Cloud Translation API 翻譯而成。

透過 WebAssembly 使用非同步網路 API

Ingvar Stepanyan

網路上的 I/O API 皆為非同步性質，但在大多數系統語言中都是同步的。時間編譯程式碼至 WebAssembly 時，您需要將某種 API 橋接到另一個 API，而這個橋接器是 Asyncify。在這篇文章中，您將瞭解 Asyncify 的使用時機和方式，以及運作方式。

系統語言中的 I/O

先來看看 C 的簡單範例。假設您要從檔案中讀取使用者名稱並附上「Hello, (username)!」訊息：

#include <stdio.h>

int main() {
    FILE *stream = fopen("name.txt", "r");
    char name[20+1];
    size_t len = fread(&name, 1, 20, stream);
    name[len] = '\0';
    fclose(stream);
    printf("Hello, %s!\n", name);
    return 0;
}

此範例雖然並不完善，但已展示了應用程式中的功能無論是從外部世界讀取部分輸入內容並在內部處理輸入內容就會輸出回外部世界所有這類與外界互動的方式函式，一般稱為輸入/輸出函式，也縮短為 I/O。

如要從 C 讀取名稱，至少需要兩次重要的 I/O 呼叫：fopen、開啟檔案，以及 fread 才能從執行個體讀取資料。擷取資料後，您可以使用另一個 I/O 函式 printf 將結果列印到控制台

這些函式乍看之下很簡單，因此您不必重複思考讀取或寫入資料所需的機器然而，視環境而定內部工作：

如果輸入檔案位於本機磁碟中，應用程式需要執行一系列的找出檔案的位置、檢查權限、開啟檔案讀取，讀取區塊，直到擷取要求的位元組數為止。作業速度可能相當慢取決於磁碟速度和要求的大小
或者，輸入檔案可能位於掛接的網路位置，在這種情況下，網路位置現在也會使用堆疊，增加複雜度、延遲並增加每次作業的重試。
最後，即使是 printf 也不保證會將內容列印到控制台，且可能會重新導向檔案或網路位置遇到這種情況時，必須按照上述步驟進行。

說來太長，I/O 時間可能很慢，而且您無法預測特定通話要花多久時間。剛才看過所有程式碼這項作業執行時，整個應用程式會顯示為凍結沒有回應使用者

這也不限於 C 或 C++。多數系統語言會以同步 API舉例來說，如果您將範例轉譯為 Rust，API 看起來會比較簡單，相同的原則您只需發出呼叫，然後同步等待呼叫傳回結果。同時執行所有昂貴作業，最後將結果傳回在單一叫用：

fn main() {
    let s = std::fs::read_to_string("name.txt");
    println!("Hello, {}!", s);
}

但當您嘗試將這些範例編譯到 WebAssembly 並轉譯為網路？提供具體範例，證明應該「讀取檔案」每個作業都會轉譯到嗎？會需要讀取某些儲存空間中的資料

網頁的非同步模型

網路提供各種可以對應的儲存空間選項，例如記憶體內儲存空間 (JS) 物件)、localStorage、 IndexedDB、伺服器端儲存空間和新的 File System Access API。

不過，這些 API 只能使用兩種 API，也就是記憶體內儲存空間和 localStorage 而且兩者都是限制最多的儲存資料與時間長度選項。所有語言其他選項只提供非同步 API。

這是在網路執行程式碼的核心屬性之一，就是任何耗時的作業。包括任何 I/O 都必須以非同步方式運作

原因是網路一直以來都是單一執行緒，以及任何涉及 UI 的使用者程式碼必須在與 UI 相同的執行緒上執行還必須與其他重要任務互相競爭以便處理 CPU 作業時間的版面配置、轉譯和事件處理不想使用 JavaScript WebAssembly 可以開始「讀取檔案」這項作業會封鎖所有其他項目例如整個分頁或過去使用整個瀏覽器，從毫秒到數秒不等，直到設定完畢為止。

相反地，程式碼只能排定 I/O 作業與要執行回呼的時間訓練完成後這類回呼會在瀏覽器的事件迴圈中執行。我不會會詳細說明但若你想瞭解事件迴圈的運作方式退房工作、微工作、佇列和排程這部影片會深入說明這個主題

簡易版是指瀏覽器以無限迴圈的形式執行所有程式碼逐一移除佇列中的這些事件觸發某些事件時，瀏覽器會將而在下一個迴圈疊代時，會從佇列中移除並執行。此機制可模擬並行，以及執行大量平行作業，同時只用於單一執行緒。

請務必記住這個機制，但您的自訂 JavaScript (或 WebAssembly) 程式碼執行時，事件迴圈會遭到封鎖。取得 I/O 結果的唯一方法，就是註冊回呼、完成執行程式碼，並將控制傳回瀏覽器，讓瀏覽器處理任何待處理工作I/O 完成後，處理常式就會成為其中一個工作設定要執行的裝置

舉例來說，如果您想以新型 JavaScript 改寫上述範例，且決定遠端網址，則應使用 Fetch API 和 async-await 語法：

async function main() {
  let response = await fetch("name.txt");
  let name = await response.text();
  console.log("Hello, %s!", name);
}

雖然看起來是同步的，但實際上每個 await 基本上都是回呼：

function main() {
  return fetch("name.txt")
    .then(response => response.text())
    .then(name => console.log("Hello, %s!", name));
}

在這個脫糖示例中，有一點更為明確，系統會開始要求，並透過第一個回呼訂閱回應。瀏覽器收到初始回應後，只會收到 HTTP 標頭—它會以非同步方式叫用此回呼。回呼會使用使用 response.text()，並透過另一個回呼訂閱結果。最後，一旦 fetch 將擷取了所有內容，這個方法會叫用最後一個回呼，顯示「Hello, (使用者名稱)!」加入控制台。

多虧這些步驟非同步特性，原始函式能夠將控制項回復到排定 I/O 時間後，請保留整個使用者介面；其他工作，包括轉譯、捲動等，而 I/O 在背景中執行。

最後是一個例子，即使是簡單的 API (如「休眠」)，導致應用程式等待指定的秒數，也是 I/O 作業的一種形式：

#include <stdio.h>
#include <unistd.h>
// ...
printf("A\n");
sleep(1);
printf("B\n");

當然，你可以直接翻譯，這樣會阻擋目前的執行緒直到到期為止：

console.log("A");
for (let start = Date.now(); Date.now() - start < 1000;);
console.log("B");

實際上，這就是 Emscripten 在預設實作方法中「睡著」但效率很低，不僅會封鎖整個使用者介面，而且不允許處理任何其他事件同時。通常請勿在實際工作環境的程式碼中執行此操作。

其實是更慣用的「睡眠」版本就是呼叫 setTimeout() 訂閱：

console.log("A");
setTimeout(() => {
    console.log("B");
}, 1000);

這些範例和 API 有什麼共通點？在每個例子中都使用原始的慣用程式碼系統語言會針對 I/O 使用封鎖 API，另一個網路範例則使用非同步 API編譯至網路時，您需要如何在兩者之間轉換執行模型，而且 WebAssembly 目前還沒有這項功能。

利用 Asyncify 彌補不足之處

這就是 Asyncify 的作用。Asyncify 指的是 Emscripten 支援的編譯時間功能能夠暫停整個程式以便稍後以非同步的方式恢復

呼叫圖表
描述 JavaScript ->WebAssembly ->Web API ->非同步工作叫用，而 Asyncify 會連結
將非同步工作的結果傳回 WebAssembly

搭配 Emscripten 用於 C / C++

如果是最後一個範例，要使用 Asyncify 執行非同步睡眠如下所示：

#include <stdio.h>
#include <emscripten.h>

EM_JS(void, async_sleep, (int seconds), {
    Asyncify.handleSleep(wakeUp => {
        setTimeout(wakeUp, seconds * 1000);
    });
});
…
puts("A");
async_sleep(1);
puts("B");

EM_JS是巨集，可將 JavaScript 程式碼片段定義為 C 函式。在內部使用函式 Asyncify.handleSleep()敬上這會指示 Emscripten 暫停程式，並提供應當使用的 wakeUp() 處理常式非同步作業完成後呼叫在上例中，處理常式會傳送到 setTimeout()，但它可用於任何其他接受回呼的內容。最後，您可以您可以像一般 sleep() 或任何其他同步 API 一樣，隨時呼叫 async_sleep()。

編譯這類程式碼時，您需要指示 Emscripten 啟用 Asyncify 功能。操作方法如下：傳遞 -s ASYNCIFY 與 -s ASYNCIFY_IMPORTS=[func1, func2] 可能非同步的函式清單 (類似陣列)。

emcc -O2 \
    -s ASYNCIFY \
    -s ASYNCIFY_IMPORTS=[async_sleep] \
    ...

這讓 Emscripten 知道，呼叫這些函式時可能需要儲存和還原因此編譯器會在這類呼叫周圍插入支援程式碼。

現在，在瀏覽器中執行這段程式碼時，就會看到與您預期的無縫輸出記錄。 B 會在 A 之後短暫延遲

A
B

您可以傳回以下來源的值：非同步函式。內容您需要傳回 handleSleep() 的結果，然後將結果傳遞至 wakeUp() 回呼。例如，如果您希望從遠端擷取數字，而非讀取檔案資源，您可以使用如下的程式碼片段發出要求、暫停 C 程式碼，以及擷取回應主體後繼續執行 - 所有作業都像同步呼叫一樣順暢完成。

EM_JS(int, get_answer, (), {
     return Asyncify.handleSleep(wakeUp => {
        fetch("answer.txt")
            .then(response => response.text())
            .then(text => wakeUp(Number(text)));
    });
});
puts("Getting answer...");
int answer = get_answer();
printf("Answer is %d\n", answer);

事實上，如果是以 Promise 為基礎的 API (例如 fetch())，您甚至能結合 Asyncify 和 JavaScript 的 async-await 功能，而非使用回呼式 API。為此 Asyncify.handleSleep()，呼叫 Asyncify.handleAsync()。接著，就不必逐一安排 wakeUp() 回呼可以傳遞 async JavaScript 函式，並使用 await 和 return 讓程式碼看起來更自然且同步，同時又不會失去非同步 I/O

EM_JS(int, get_answer, (), {
     return Asyncify.handleAsync(async () => {
        let response = await fetch("answer.txt");
        let text = await response.text();
        return Number(text);
    });
});

int answer = get_answer();

正在等待複雜值

但本範例仍限制您只能使用數字。如果想將原始版和 YAML 檔案我在哪裡以字串形式從檔案中取得使用者名稱？別擔心，您也可以做到！

Emscripten 提供稱為 Embind，亦即處理 JavaScript 和 C++ 值之間的轉換。它也支援 Asyncify，因此您可以對外部 Promise 呼叫 await()，其運作方式與 async-await 中的 await 相同 JavaScript 程式碼：

val fetch = val::global("fetch");
val response = fetch(std::string("answer.txt")).await();
val text = response.call<val>("text").await();
auto answer = text.as<std::string>();

使用這個方法時，您甚至不需要將 ASYNCIFY_IMPORTS 做為編譯標記傳遞，系統預設會納入該參數

好的，在 Emscripten 中都能順利使用。還有哪些工具鍊和語言？

其他語言的使用情形

假設您在 Rust 程式碼中有類似的同步呼叫，且想對應至 async API結果顯示，您也可以這麼做！

首先，您需要透過 extern 區塊 (或您選擇的) 將這類函式定義為一般匯入作業外文函式的語法)。

extern {
    fn get_answer() -> i32;
}

println!("Getting answer...");
let answer = get_answer();
println!("Answer is {}", answer);

將程式碼編譯為 WebAssembly：

cargo build --target wasm32-unknown-unknown

現在，您需要使用可儲存/還原堆疊的程式碼，檢測 WebAssembly 檔案。適用於 C / C++ 和 Emscripten 會替我們這麼做，但這裡不會用到，因此這個程序比較手動。

幸好，Asyncify 轉換本身完全適用於各種工具鍊。可以任意轉換 WebAssembly 檔案，無論它是由哪個編譯器產生的檔案都一樣。轉換會分開提供此為 Binaryen 的 wasm-opt 最佳化工具之一。工具鍊，並以下列方式叫用：

wasm-opt -O2 --asyncify \
      --pass-arg=asyncify-imports@env.get_answer \
      [...]

傳遞 --asyncify 來啟用轉換，然後使用 --pass-arg=… 提供以半形逗號分隔非同步函式清單，其中程式狀態應暫停，並在稍後繼續執行。

接下來只提供支援執行階段程式碼，這些程式碼可以實際執行，即暫停使用並繼續 WebAssembly 程式碼。再次提醒，在 C / C++ 案例中，Emscripten 會納入這部分，但您現在需要可處理任意 WebAssembly 檔案的自訂 JavaScript 黏合程式碼。我們已建立程式庫分享這些資料

您可以在 GitHub 的以下網址找到該檔案： https://github.com/GoogleChromeLabs/asyncify or npm (位於名稱：asyncify-wasm) 下。

可模擬標準的 WebAssembly 例項化 API，但在各自的命名空間下執行。只有差別在於，在一般 WebAssembly API 下，您只能提供同步函式，匯入，而在 Asyncify 包裝函式下，您也可以提供非同步匯入：

const { instance } = await Asyncify.instantiateStreaming(fetch('app.wasm'), {
    env: {
        async get_answer() {
            let response = await fetch("answer.txt");
            let text = await response.text();
            return Number(text);
        }
    }
});
…
await instance.exports.main();

當您嘗試從呼叫這類非同步函式時 (如上述範例中的 get_answer())， WebAssembly 端的程式庫會偵測傳回的 Promise，然後暫停並儲存 WebAssembly 應用程式、訂閱承諾完成，並在問題解決後，順暢還原呼叫堆疊和狀態，並在沒有任何發生的情況下繼續執行作業。

由於模組中的任何函式都可能進行非同步呼叫，因此所有匯出內容都可能成為所以系統也能順利包裝您可能在上述範例中發現您需要 await instance.exports.main() 的結果，才能得知何時確實執行已完成。

這些功能實際上是如何運作的？

當 Asyncify 偵測到對其中一個 ASYNCIFY_IMPORTS 函式的呼叫時，就會啟動非同步作業作業，儲存應用程式的完整狀態，包括呼叫堆疊及任何本機儲存和呼叫堆疊，並在作業完成後還原所有記憶體和呼叫堆疊，會從相同位置繼續，狀態會與程式從未停止的狀態相同。

這與我稍早顯示的 JavaScript 中的 async-await 功能相似，不需要任何特殊的語法或執行階段支援這類語言，的運作方式是在編譯期間轉換純同步函式。

編譯先前顯示的非同步睡眠範例時：

puts("A");
async_sleep(1);
puts("B");

Asyncify 會參考這個程式碼，將其轉換為大致上類似下方的程式碼 (虛擬程式碼、真實不涉及以下行為：

if (mode == NORMAL_EXECUTION) {
    puts("A");
    async_sleep(1);
    saveLocals();
    mode = UNWINDING;
    return;
}
if (mode == REWINDING) {
    restoreLocals();
    mode = NORMAL_EXECUTION;
}
puts("B");

初始 mode 設為 NORMAL_EXECUTION。相對地，第一次這類轉換到的程式碼，系統只會評估 async_sleep() 之前的部分。一旦非同步作業為排程，Asyncify 會儲存所有本機檔案，從每個函式一路回到頂端，此做法讓瀏覽器擁有控制權事件迴圈

當 async_sleep() 解析後，Asyncify 支援代碼就會從 mode 變更為 REWINDING，且再次呼叫函式。這次會略過 - 因為已上次執行這項工作，但我想避免顯示「A」而是直接提供給「倒轉」觸及完成後，它會還原所有儲存的本機資料，並將變更模式改回「標準」並繼續執行程式碼，就好像從一開始就從未停止程式碼。

轉型費用

可惜的是，Asyncify 轉換必須插入大量提供程式碼，用於儲存及還原所有本機資料，並瀏覽各種模式等等它會嘗試只修改指令上標示為非同步的函式程式碼大小和可能呼叫的呼叫端，但程式碼大小負擔可能仍會加起來約 50% 再壓縮。

顯示程式碼的圖表
。
案件

這並不理想，但在多數情況下，如果替代工具沒有提供功能或是必須大幅改寫原始程式碼

請務必一律為最終版本啟用最佳化功能，避免效能提升。你可以也會勾選 Asyncify 特定最佳化各種選項僅限指定函式和/或直接函式呼叫。此外，您也可以參考執行階段效能的成本較低，但僅限於非同步呼叫本身。不過，相較於其他 API 但實際工作成本通常可以忽略不計

實際示範

閱讀完幾個簡單的範例後，接下來要講解一些更複雜的情況。

如文章的開頭所述，網路上的儲存空間選項就是非同步 File System Access API。有了 Cloud Shell 從網頁應用程式導入真正的主機檔案系統

另一方面，有個名為 WASI 的不法標準。主要是以非同步的方式公開所有類型的檔案系統和其他作業同步形式。

如果可以，彼此對應呢？接著，您就能使用任何來源語言編譯任何應用程式與支援 WASI 目標的任何工具鍊執行，並且在網頁的沙箱中執行，同時確保以便在實際的使用者檔案中運作！而 Asyncify 便能派上用場。

在這個示範中，我已使用對 WASI 的一些小修補程式，透過 Asyncify 轉換傳遞，並以非同步方式實作 WASI 的繫結更新至 File System Access API與 Xterm.js 終端機元件，這可提供在和實際的使用者檔案一樣，就像使用實際的終端機一樣。

詳情請造訪 https://wasi.rreverser.com/。

非同步用途不僅限於計時器和檔案系統。如要進一步在網路上使用更多小眾 API。

舉例來說，在 Asyncify 的協助下， libusb - 是最適合搭配使用的原生資料庫 USB 裝置至 WebUSB API，可讓這類裝置以非同步方式存取這類裝置在網路上。完成繪製及編譯後，我就取得了標準的 Libusb 測試和範例裝置。

Libusb 螢幕截圖
網頁上的偵錯輸出內容，顯示已連線 Canon 相機的資訊

也許是另一篇網誌文章的故事。

這些範例展現了 Asyncify 的威力，可說是消弭落差，多種應用程式部署至網路，方便您取得跨平台存取權、採用沙箱機制，以及安全性，同時確保功能不會遺失。