Давайте расскажу, какие сейчас вообще дела. Мигрировал с wasmer на wasmtime (wasm-рантаймы), психанул, хоть и проблема была всё-таки в моём коде, неправильно глянул на документацию Vec::reserve(), передал туда меньше чем нужно, затем словил такие страшные спецэффекты, что вообще не понимал, что происходит, т.к. программа то выдавала мусор, то ломалась от добавления format!(), в общем, мрак. В процессе дебага попробовал повызывать свой васм из браузера, вполне себе получилось и там ничего не крешилось (но как оказалось я неправильно потестил, функция ломалась на втором вызове), списал всё на рантайм и сменил.
Но я и так собирался на wasmtime мигрировать. Во-первых там с wasm-памятью работа сильно тупее и проще. Во-вторых там есть поддержка асинхронных хост-функций, чтобы можно было в хост-функции вызвать что-нибудь асинхронное и продолжить выполнять wasm-код когда операция завершится. В будущем оно мне будет нужно, функции-обработчики данных должны иметь возможность попросить посмотреть/записать в какую-нибудь другую коллекцию. Хотя и в wasmer это можно было бы сделать, если заиспользовать крейт, который мощными asm-колдунствами умеет переключать текущий стек. Тогда можно выделить отдельный стек для того, что выполняется из васма, начать его выполнять, а когда он вызовет нашу хост-функцию — попросить переключить стек на тот, что был, выполнить нужную асинхронщину, вернуться обратно и продолжить. Возможно и wasmtime под капотом делает то же самое, но тут это нативная операция библиотеки и возможно она делает это как-то эффективнее, будет оптимизирована в будущем и всё такое. В общем, поживём — увидим (оправдываюсь, да).
Бизнес-логику агрегаций дореализовал, теперь у меня есть штуковина, которая стопудов как-то обзывается в паттернах проектирования. Она сама по себе ничего не делает, но говорит, какие данные ей нужно предоставить/какую кастомную функцию выполнить/какие запросы нужно совершить и так её можно вызывать в цикле, получая от неё команды и подсовывая в неё данные, пока она не скажет, что всё готово.
Сейчас занимаюсь тестовым фреймворком пользовательских агрегаций. Для map/filter операции оно уже есть, там описываешь что хочешь превращать одну коллекцию в другую, говоришь путь до wasm-файла, какие функции из него нужно использовать, ну и оно работает. Но wasm нетривиально тестировать, поэтому в yaml-файле конфига можно задать секцию тестов, где говоришь «давай прогоним вон ту трансформацию на вот таких вот данных, вот такой результат должен получиться». Дополнительно дореализовываешь функций которые умеют сериализированные входные/выходные данные в байты превращать и наоборот (либо делать noop, если данные строковые), запускаешь, оно шух-шух и прям как полагается пишет OK/FAIL на каждый тест и говорит что разошлось (даже диффалку прикрутил, красивое).
#diffbelt
Но я и так собирался на wasmtime мигрировать. Во-первых там с wasm-памятью работа сильно тупее и проще. Во-вторых там есть поддержка асинхронных хост-функций, чтобы можно было в хост-функции вызвать что-нибудь асинхронное и продолжить выполнять wasm-код когда операция завершится. В будущем оно мне будет нужно, функции-обработчики данных должны иметь возможность попросить посмотреть/записать в какую-нибудь другую коллекцию. Хотя и в wasmer это можно было бы сделать, если заиспользовать крейт, который мощными asm-колдунствами умеет переключать текущий стек. Тогда можно выделить отдельный стек для того, что выполняется из васма, начать его выполнять, а когда он вызовет нашу хост-функцию — попросить переключить стек на тот, что был, выполнить нужную асинхронщину, вернуться обратно и продолжить. Возможно и wasmtime под капотом делает то же самое, но тут это нативная операция библиотеки и возможно она делает это как-то эффективнее, будет оптимизирована в будущем и всё такое. В общем, поживём — увидим (оправдываюсь, да).
Бизнес-логику агрегаций дореализовал, теперь у меня есть штуковина, которая стопудов как-то обзывается в паттернах проектирования. Она сама по себе ничего не делает, но говорит, какие данные ей нужно предоставить/какую кастомную функцию выполнить/какие запросы нужно совершить и так её можно вызывать в цикле, получая от неё команды и подсовывая в неё данные, пока она не скажет, что всё готово.
Сейчас занимаюсь тестовым фреймворком пользовательских агрегаций. Для map/filter операции оно уже есть, там описываешь что хочешь превращать одну коллекцию в другую, говоришь путь до wasm-файла, какие функции из него нужно использовать, ну и оно работает. Но wasm нетривиально тестировать, поэтому в yaml-файле конфига можно задать секцию тестов, где говоришь «давай прогоним вон ту трансформацию на вот таких вот данных, вот такой результат должен получиться». Дополнительно дореализовываешь функций которые умеют сериализированные входные/выходные данные в байты превращать и наоборот (либо делать noop, если данные строковые), запускаешь, оно шух-шух и прям как полагается пишет OK/FAIL на каждый тест и говорит что разошлось (даже диффалку прикрутил, красивое).
#diffbelt