圖片來源: 

Mozilla

新一代網頁格式WebAssembly提供極佳的執行效率,讓瀏覽器也能夠執行像是遊戲或是Photoshop這類重量級網頁應用程式,而Mozilla要進一步擴充WebAssembly的可移植性,讓WebAssembly應用程式順利跨出瀏覽器,因此開始推動WebAssembly系統介面WASI,使WebAssembly能以更直覺的方式與系統核心溝通。

由於WebAssembly是一個概念機器(Conceptual Machine)而非物理機器的組合語言,因此可以在不同的平臺上執行,而要讓WebAssembly在瀏覽器之外,還能在不同的作業系統上執行,需要一個概念作業系統的系統介面,而這正是Mozilla致力制定WebAssembly系統介面WASI的原因,以擴展WebAssembly到更多的平臺。

一般應用程式可以透過系統呼叫,請求作業系統核心執行特定操作,在多數的裝置上,這是程式碼可以存取系統資源的唯一方法,而由於多數開發語言都有標準函式庫,因此開發者也不需要知道不同作業系統的實作,只要知道怎麼使用介面就行了,當程式碼在編譯的時候,工具鍊會依照程式碼目標系統,選擇需要的介面實作,而這個實作則取決於作業系統API的函式,每個作業系統有所區別,像是對Windows機器就會使用Windows API,為Mac或Linux機器編譯就會使用POSIX。

但這樣的模式卻無法套用到WebAssembly上,在WebAssembly編譯階段,系統仍然不知道應用程式的目標作業系統,因此也無法在標準函式庫的WebAssembly實作,使用單一作業系統的介面。雖然現在WebAssembly已經可以在瀏覽器之外執行,但是卻使用非正規的方法。

Emscripten編譯工具在網頁上模擬作業系統介面POSIX,讓開發人員特以使用C標準函式庫中的函式,為此Emscripten創建了C標準函式庫的實作,實作分為兩部分,一部分編譯成WebAssembly模組,另一部分則以JavaScript中介程式碼實作,而JavaScript中介程式碼會呼叫瀏覽器與作業系統溝通。

要在沒有瀏覽器的情況下執行WebAssembly,執行的Runtime需要實作JavaScript中介程式碼中的函式,Mozilla提到,這些JavaScript中介程式碼的介面並非為標準而設計,甚至還對外公開。因此這只能作為暫時的解法,為了WebAssembly生態系統的長久發展,需要尋求更根本的解決方案。

為了要保持WebAssembly的可移植性以及安全性,Mozilla提出了WebAssembly系統介面解決方案,建構一套模組化的標準介面,而這項工作從最基礎的wasi-core開始,wasi-core將包含所有應用程式需要的基礎,包括檔案、網路連接、時間以及隨機數字等POSIX功能,來允許應用程式執行開啟、關閉、讀取或是寫入檔案等工作。

但wasi-core也不會涵蓋POSIX的所有部分,像是程序概念就不會完全映射到WebAssembly上,而每個WebAssembly引擎也不需要支援像是fork這樣的程序操作。Mozilla表示,模組化的好處在於讓利基平臺可以只使用適合的WASI部分,像是Rust就能直接在標準函式庫使用wasi-core,對C和C++而言,則可以使用C標準函式庫實作wasi-sysroot。Mozilla希望Clang這類編譯器也可以與WASI API相容,像Rust編譯器和Emscripten等工具鏈,把WASI納入系統實作中。

Mozilla表示,wasi-core是WebAssembly正式跨出網頁的第一步,並為其生態系統建立了良好的基礎,而在wasi-core完全標準化之後,還需要解決非同步I/O、檔案監控與檔案鎖定等工作。

 


Advertisement

更多 iThome相關內容