Следом за технологией WASI (https://www.opennet.ru/opennews/art.shtml?num=50406) (WebAssembly System Interface), нацеленной на использование WebAssembly вне браузера, представлен (https://www.fastly.com/blog/announcing-lucet-fastly-native-w...) проект Lucet (https://github.com/fastly/lucet), предлагающий компилятор lucetc и runtime для выполнения программ в формате WebAssembly. Lucet позволяет скомпилировать модули в псевдокоде WebAssembly (.wasm или .wat) в машинный код, пригодный прямого исполнения. Результат сохраняется в виде разделяемой библиотеки или объектных файлов, которые можно связать с приложениями на языках Си или Rust. Код проекта написан на языке Rust и распространяется (https://github.com/fastly/lucet) под лицензией Apache 2.0.
Основной задачей проекта является предоставление возможности безопасного исполнения сторонних программ на WebAssembly внутри других приложений (например, для реализации плагинов). Исходные приложения для встраивания могут быть написаны на языках Си (компилируется в WebAssembly при помощи clang), Rust и AssemblyScript (https://github.com/AssemblyScript/assemblyscript) (TypeScript). Для использования в окружении WebAssembly предлагается Си-библиотека lucet-builtins, предоставляющая базовые функции libc.Проектом поставляется runtime для модулей, скомпилированных при помощи lucetc. Указанный runtime предоставляет функции для загрузки модулей из объектных файлов, их активации и организации вызова функций из базового приложения. Lucet-runtime также выполняет задачи по управлению ресурсами для каждого экземпляра WebAssembly и обработке исключений, возникающих при сбоях. Компонент может использоваться как crate-пакет для Rust или как разделяемая библиотека для Си.
Дополнительно предлагается Lucet-wasi, расширение к runtime с реализацией режима изоляции и системных прослоек WASI (https://www.opennet.ru/opennews/art.shtml?num=50406), позволяющих напрямую запускать WebAssembly-приложения с применение расширенных механизмов контроля доступа и с возможностью обращения к ресурсам системы (файлы, сокеты и т.п.). Lucet-wasi также может использоваться в виде библиотеки для интеграции поддержки WASI в другие приложения. В настоящее время lucet-wasi пока поддерживает только запуск в Linux-системах на базе архитектуры x86-64.
Код открыт компанией Fastly, которая использует Lucet в качестве основы движка облачных вычислений, использующего WebAssembly для обработчиков. Так как модель "edge cloud" подразумевает запуск обработчика на каждый запрос, а запросов может быть десятки тысяч в секунду, проект изначально рассчитан на потребление минимальных ресурсов и очень быстрый запуск новых экземпляров окружений для выполнения WebAssembly. Запуск модуля WebAssembly производится менее чем на 50 микросекунд, а дополнительное потребление памяти составляет всего несколько килобайт на каждый экземпляр (для сравнения движок Chromium V8 требует для запуска JavaScript или WebAssembly 5 миллисекунд и десятки мегабайт).
Для достижения подобного уровня производительности программы WebAssembly запускаются в рамках одного процесса с изоляцией на уровне runtime, который предоставляет каждой программе WebAssembly доступ только к собственным ресурсам. В отличие от других окружений для выполнения WebAssembly, в Lucet используется не JIT, а полноценная упреждающая компиляция в машинный код (AOT, ahead-of-time).URL: https://www.fastly.com/blog/announcing-lucet-fastly-native-w...
Новость: https://www.opennet.ru/opennews/art.shtml?num=50418
ожидаемоа вообще всё плохо, а будет ещё хуже.. ага
А зачем городить лишние сущности?
В примерах берут код на Си, компилируют clang-ом в WebAssembly, а потом WebAssembly компилируют в машинный код. Почему сразу в машинный код не скомпилить в shared-библиотеку, а для изоляции какой-нибудь готовый sandbox не использовать? Тот же Sandboxed API от Google о котором новость пару недель назад была https://www.opennet.ru/opennews/art.shtml?num=50349
Напрямую скомпилированный машинный код, во-первых, не переносим, во-вторых, не предотвращает фокусов вроде манипуляции указателями или прямого вызова сисколлов, а исполнять ведь предполагается засланный пользователем код. Да и си там, скорее, для примера взят, в большинстве своём люди всё равно будут компилировать из привычных им джаваскриптов.Здесь скорее напрашивается вопрос о причинах NIH при наличии JVM/CLR.
Зачем исплнять код, которому не доверяешь?
Чтобы деньги за это получать же.
джаваскрипты в wasm? Где ж такое? Знаю си, плюсы, вроде go был... джаваскрипт в wasm совать - это вообще бессмвыслица какая-то
Наоборот, вебмакаки ликуют. Теперь, вместо изучения нормального языка для разработки нормальных приложений, достаточно будет в свой вебпук.жиэс поставить плагин, который будет компилять их творчество в васм. Вебмакаки целы и юзеры довольны производительности.
Я вот джва года жду транслятор wasm -> llvm.
wasm это таргет llvm. Какой смысл обратно компилить, да ещё и с потерей информации?
>Какой смысл обратно компилить, да ещё и с потерей информации?Очевидно же - когда нет исходника.
То есть вы планируете запускать код не имея исходников? присылайте мне wasm бинарник, я сконвертирую.
Смысл в том, чтобы почти похоронить пакеты, специфичные для архитектур. То есть я компилирую нейтив-код в васм, кладу васм-байткод в пакет. При установке васм преобразуется в llvm и компилируется в нативную библиотеку, с которой можно делать всё то, что и с нативной библиотекой, собранной из C++.
>Смысл в том, чтобы почти похоронить пакеты, специфичные для архитектур. То есть я компилирую нейтив-код в васм,Не забываем, что wasm это фигня, которая по идейным соображениям безопасности не может взаимодействовать с оборудованием, а значит пользователем и сетью, зато переносимая. При таком подходе оно даже питон заменить не в силах.
> Смысл в том, чтобы почти похоронить пакеты, специфичные для архитектур.Вот это дело! Тогда и необходимость в открытых исходниках пропадёт. ;-)
Если вы считаете, что открытые исходники нужны только для того, чтобы приложение можно было пересобрать для других архитектур, то это далеко не правда.
Представляю как браузер внутри себя будет делать сначала:
$ lucetc-wasi hello.wasm -o hello.so
а потом:
$ lucet-wasi hello.so.
браузер wasm умеет исполнять прямо сейчас, никакие сторонние кмопиляторы ему для этого не нужны
Как следует из текста новости, сейчас он это умеет не слишком оптимально.
идея как раз в том чтоб компилировать однажды исполнять wasi напрямую без компиляции
> Результат сохраняется в виде разделяемой библиотеки или объектных файлов, которые можно связать с приложениями на языках Си или Rust. [...] возможности безопасного исполнения сторонних программ на WebAssembly внутри других приложенийразбежались с "безопасным".
Спектр (который будут исправлять последущие 10 лет) не даст возможности так просто взять и "безопасно" исполнить
поруби таймеры и будет счастье. Впрочем, что-то другое найдётся. Песочницы и недоверенный код - это всегда игры с огнём.
Одни и те же библиотеки для браузера и десктопа. Да еще и на любом компилируемом языке...
Разработчики молодцы, раньше о таком только и мечтать можно было.
Как Java-апплеты?
Как ActiveX + .Net или как Silverlight
Нет java апплеты нужны были для взаимодействия с оборудованием через песочницу. WASM чистая числодробилка.
еще одно ненужно типа электрон.))
> еще одно ненужно типа электрон.))ну полезность электрона в том что он отвлёк на себя горе-программистов (js-обезъянок со своими реактами)
А чем это отличается от "программа на любом языке" которая общается с внешним миром через "безопасную" libc (ну например на rust) с изоляцией и контролем доступа?
А чем это отличается от "программа на любом языке" которая общается с внешним миром через "безопасную" libc (ну например на rust) с изоляцией и контролем доступа?
Теперь таки можно будет написать язык программирования где целевое использование будет WebAssembly, а при желании можно в нативный код при помощи упомянутого инструмента. Зачем? Just for fun, конечно же. Как минимум вариация на тему WebAssembly Little C без оптимизаций и просто более читаемое представление того что будет уже в "ASM" от WebAssembly. Бесполезно, но интересно.
> можно будет написать язык программирования где целевое использование будет WebAssembly
замечательно - а есть pascal там поддерживается?
Вы вспоминаете свой любимый язык в каждой новости про программирование. Очевидно, Вам не дает покоя мысль, что давая Вам его в 90-х в школах РФ, Вас намеренно или по глупости заставили учить то, что никому не сдалось, особенно в остальной вселенной.
> что давая Вам его в 90-х в школах РФ, Вас намеренно или по глупости заставили учить то, что никому не сдалось, особенно в остальной вселенной.Специалиста-знатока по школам вне РФ, ненужности навыка написания чистого и структурированного кода и вообще, по целым вселенным, вижу я.
Отчего-то правда создается впечатление, что спицилист сугубо опеннетный, у которого от упоминания паскаля просто начинает подпекать.
просто оставлю это сдесь
"37 apps in our registry" - странно что так мало, язык же действительно хороший.
Тебе нужно - напиши патч.
Вася поверх Люси? Извращенцы какие-то))