Спичка, заключенная на небесах
WebAssembly - отличная технология. Это делает наши приложения повсеместными, так что они могут работать где угодно: от браузеров до серверов, от Windows до Unix, от настольных компьютеров до мобильных устройств ...
Я знаю, JavaScript уже делает это! 🚶♂️
… но хоть и не так быстро. 🏃♂️
Итак, когда приложения скомпилированы в WebAssembly, как мы можем гарантировать, что они работают на всех платформах?
Или, другими словами, какой ABI лучше всего подходит для всех приложений?
Начнем с самого начала ...
Что такое ABI?
ABI расшифровывается как Application Binary Interface (страница вики).
Мы можем рассматривать ABI как контракт между двумя двоичными приложениями, чтобы гарантировать, что один двоичный файл может получить доступ к определенным собственным функциям из другого двоичного файла.
Каждый раз, когда мы компилируем приложение C или C ++, существует набор системных вызовов, которые приложение обычно будет использовать, например, чтобы открыть файл, прочитать его содержимое ... или даже открыть сокет.
Для этого приложения обычно нацелены на POSIX ABI для запуска этих системных вызовов в Unix-подобных системах. После POSIX существуют различные реализации, такие как libc, musl…
WebAssembly ABI
Ту же концепцию можно применить, когда мы компилируем приложения в WebAssembly. Какой самый общий и полный набор системных вызовов, который мы должны там запускать?
Это наиболее часто используемые стратегии ABI для WebAssembly:
- Emscripten: Emscripten определяет подмножество поверх POSIX ABI.
Его основной целью было выполнение приложений C / C ++ внутри браузера. Таким образом, большинство системных вызовов эмулируются в JavaScript (например, вызовы файловой системы или сокетов). - Go: Go не определяет явного ABI. Различные зависимости могут включать собственный экспорт в импортированные функции WebAssembly. Это очень гибкий подход, но он может запутаться при попытке достичь платформенно-независимого приложения.
Однако Олин использует интересный подход для своего ABI. - Rust: пока нет официального ABI для WebAssembly. Однако существуют определенные инструменты, такие как wasm-bindgen, которые помогают при взаимодействии между WebAssembly и другими языками (сейчас в основном это JavaScript).
В настоящее время Wasmer поддерживает только Emscripten. Но, Почему?
Сосредоточение внимания на запуске сгенерированных Emscripten модулей WebAssembly (таких как Nginx и Lua!) Помогло нам создать доказательство концепции, прежде чем возникла необходимость в построении всей цепочки инструментов на ее основе.
Но… было бы неплохо, если бы был общий ABI, который Go, Rust, C, C ++ и т. Д. Могли бы использовать в качестве цели, будучи независимыми от платформы?
Таким образом, нам нужно будет реализовать ABI только один раз и обеспечить легкое взаимодействие между различными скомпилированными модулями WebAssembly на любой платформе и в любом контексте.
PWSIX: POSIX для WebAssembly
Одна из инициатив, которая, по нашему мнению, будет продолжаться в долгосрочной перспективе, будет заключаться в создании нового ABI, такого как POSIX, но созданного специально для сред WebAssembly: PWSIX.
Однако мы все еще далеки от определения стандарта, который подходил бы для всех платформ с общим набором системных вызовов. Поэтому мы думаем, что на краткосрочную перспективу может быть более простая стратегия: CloudABI.
CloudABI
CloudABI был создан с целью предоставить общий механизм разрешений поверх системных вызовов.
WebAssembly предоставляет безопасную песочницу, которая позволяет программе вызывать только функции, предоставляемые средой хоста. CloudABI - это минимальный API в стиле POSIX, который позволяет строго контролировать ресурсы, к которым программе разрешен доступ. Комбинируя безопасную песочницу и среду узла безопасности, основанную на возможностях, можно получить новые детализированные вычисления, без накладных расходов на контейнеры или виртуализацию.
Вместо того, чтобы разрешать приложениям открывать произвольные файлы на диске и подключаться к произвольным системам в сети, вы как пользователь точно вводите те ресурсы, к которым приложение должно получить доступ
- nuxi.nl
Итак, чему мы можем научиться у CloudABI?
Помимо введения концепции разрешений на выполнение определенных системных вызовов, он также сокращает количество системных вызовов, необходимых для реализации до 49.
Вот отличное введение о преимуществах использования CloudABI:
Так что же дальше?
Мы надеемся увидеть больше инструментов для WebAssembly и CloudABI, так что часто используемые библиотеки могут начать работать с ними.
Как только экосистема WebAssembly & CloudABI будет развиваться, мы быстро поддержим ее в Wasmer!
Благодаря тому, что библиотеки разделены на разные обязанности, на самом деле довольно легко подключить новые интеграции поверх WebAssembly.
Нам не терпится увидеть весь инструментарий, который будет создан вокруг CloudABI в будущем… мы будем готовы к этому, когда придет время!
Понравилась статья? Вам нравится WebAssembly?
Свяжитесь со мной по адресу [email protected] … мы нанимаем!
