летней давности. лол.
https://github.com/TheNeikos/rustbreak/blob/master/examples/server/src/main.rs
@iccsf что скажешь?
Ну это как раз in-memory штука, которая делает как раз то, что я описывал. И проблемы у неё те же самые существуют, которые я описывал: там в save RwLock лочится на чтение, так что пока все данные не будут сериализованы, ты базу менять не можешь, только читать. А ещё там RwLock и мутекс из std, а не из parking_lot, так что писатели могут голодать на твоей базе, если неаккуратно будешь пользоваться.
что значит голодать
"проблема" тут значит, что вообще не будет работать, или будет но иногда медленно? меня второе в принципе устраивает
Запись зависать будет примерно как stop-the-world GC, каждый раз когда ты вызываешь save.
https://docs.rs/parking_lot/0.11.1/parking_lot/type.RwLock.html Читай тут.
а если у них апи одинаковое/почти одинаковое, но работа лучше, то почему бы просто не взять и не заменить в том крейте стандартный RwLock на этот?
честно, не понимаю в чём проблема (глупенький) в том, что чтобы что-то сериализовать это надо сначала прочитать? (.read()) ну да, при этом блокируются запросы на .write() но их же меньше, подождут
а с частичной загрузкой-выгрузкой время и ресурсы на сериализацию можно "размазать" по времени(?)
Нет, ты же все данные лочишь. Чтобы stop-the-world не случалось, надо использовать всякие специальные CoW структуры, а это уже относительно сложно.
Ну, если твои юзеры могут подождать, то ладно. А ещё не забудь, что длительность лока линейно зависит от хранимого объёма. Какой-нибудь 1Mb у тебя мгновенно сериализуется, а вот гигабайты данных уже не очень мгновенно.
Не знаю, можешь зафигачить им PR.
Обсуждают сегодня