Если именно по OS error надо матчить, а не по ErrorKind.

Спасибо! Но мне просто проигнорировать ошибку AlreadyExists при создании директории

Вопрос знатокам - как можно решить такую задачку? https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=58363f779a0136430ad6b491fb5af1f0

—

В чём суть: есть арк на хэшмапу, нужно смутировать мапу так, чтобы те кто держат ссылки созданные до вызова функции не увидели изменений, а после - увидели. Проблема в том что нужно сделать за О(1) памяти. то есть просто саллоцировать новую мапу и подменить не вариант.

—

Как это видится у меня в голове: нужно сделать take() на None, дождаться пока счетчик ссылок упадёт до 1, и после этого спокойно мутировать его, после чего сунуть обратно. Но как это сделать чтобы борровчекер не возмущался - не знаю.

вместо Option<HashMap<K, V>> можно в целом любой тип использовать

А просто сделать структуру, которая хранит ссылку на предыдущую версию хешмапы?

тогда смысл в мапе пропадет, через какое-то время будет О(n) поиск по ключу потому что нужно будет пройтись по всем структуркам и искать там значение

Чтобы в памяти жили изменения + старая хешмапа, собственно

Чтобы прояснить XY: мне нужен ридонли локфри кэш который должна быть возможность инвалидировать

Не уверен что тебе подойдёт, но evmap это не про это как раз?

Хотя нет, сейчас читаю доку, там всё же именно конкурентная мапа, а не то что тебе нужно 🤔

да, мне не нужна полноценная конкурентная мапа, у меня раз в Х секунд только апдейт, а в остальное время можно арки спокойно шарить

да и сам апдейт меняет типа 1% мапы

текущая реалиация тупо клониирует мапу, добавляет данные, и кидает назад. Но это выливается в то что вместо 2 гигов сервису нужно 4, потому что в момент свапа назад у нас есть старая и новая копия в памяти параллельно

и вот эти 2 гига хочется срезать

Решительно не понимаю, как оно работает, там же &mut self требуется в write :(

Ручная сборка такого-же поведения с нуля — падает с ожидаемым cannot borrow data in a `& reference as mutable`. Где можно почитать про то, почему с File так работает?

Impl Write for & File

🤦‍♂️

Спасибо.)

Ну evmap утверждает что её имплементация не требует оверхэда на синхронизацию, кроме момента когда ты "обновляешь" мапу (явно через WriteHandle::refresh)

Если у тебя обновления на 1% мапы, то думаю это самое то
> For read-heavy workloads, the scheme used by this module is particularly useful. Writers can afford to refresh after every write, which provides up-to-date reads, and readers remain fast as they do not need to ever take locks.

Ну под капотом у неё, как я понял, примерно то, что я предложил, только с кучей оптимизации