ну асинхронный мутекс пусть берет

Там надо по коду смотреть, подходит ли обычный мутекс.

Но обычно асинхронный мутекс стараются не использовать.

почему?

Лучше в дб сообщения слать, а не мутексами в коде баловаться.

а если ответ базы нужен?)

или что ты имеешь ввиду

Ну там какие-нибудь callback'и или oneshot ченнелы.

видимо это вопрос к diesel’ю

спасибо!

Ну тут уж асинхронный используй, обычный на датабазу в асинке не полезет.

futures::lock::Mutex?
или из tokio?
какой для actix прокатит?

Актикс на токио же работает, нет?

пасиб

И кстати, там есть lock_owned в токио, если лайфтаймы не совпадут.

звезды сошлись! ещё раз спасибо!

Вообще, примитивы синхронизации можно использовать любые, они хорошо композируются друг с другом и с рантаймами

Вот кстати да. Я читал эту доку по асинхронному мьютексу, но у меня остался один открытый вопрос. Я сейчас порой использую асинхронный мьютекс даже для данных, потому что он тупо удобнее: обычный мьютекс возвращает Result, который ещё нужно как-то обработать и/или прокинуть наверх, или анврапнуть (но это грешно). А асинхронный - после авейта не нужно анврапать, нет "лишнего" кода, поэтому он выглядит удобнее. Отсюда вопрос: а асинхронный мьютекс разве не может быть отравлен? Что если поток упал с паникой - это автоматически 100% означает что задача будет снята с выполнения экзекьютором, и не будет позже продолжена на другом потоке? Поясните плз. Ну и в целом - насколько зашкварно использовать асинк мьютекс для данных по такой вот детской причине?

Анврапуй резалт на мутексе всегда, и всё. Он ошибку возвращает, только если предыдущий держатель мутекса запаниковал.