без функций?
Я имею ввиду state.storage.xxx...
Зачем?
Работаю со спамом, иногда у заблокированного юзера проскакивают сообщения хотя не должны. Полагаю дело в асинхронных запросах данных у фсм хранилища
Не факт, что дело в этом. Конкретнее в чём проявляется?
Какое хранилище?
Если спамить руками то большую часть времени всё ок Я делаю антиспам в несколько уровней, и поэтому есть блокировка на разные периоды времени. Если спамит юзерскрипт в бота то временами между переключениями уровней проскакивает ещё одно сообщение, что я и хочу пресечь
Делаю это в самом конце схемы, возможно это тоже влияет, хз
Потому что надо делать без фсм. Только на питоне
Ага, и держать заблокированные айди в словаре, да?
^между переключениями уровней а как уровни переключаются?
Начал спамить - бот ответит что не спамь, сука. Продолжишь - он скажет что ты пидорас, мут на 5 минут, ещё раз будешь спамить то забаню нахуй. Продолжаешь - получаешь полный игнор от бота
Как вариант
не, я в плане именно реализации изменения данных по ключу статуса юзера в сторадже, нет ли там чего-то что может привести к этому поведению?
Этому поведению - о чем речь? Про то что сообщение проскакивает?
да если я правильно понял у тебя статусы переключаются как-то так?: no_warns, restricted_first_time has_one_warn blocked
Там число но смысл примерно такой, да
ну тогда по идеи сообщение может проскочить в то время когда у юзера снимаются ограничения и ещё не установлен статус blocked
Я тоже на это думал и оптимизировал как мог
не я о том что после того как у юзера заканчивается первое ограничение он же снова может писать в чат, верно?
Да. Я щас пытаюсь свой говнокод привести в красивый ООПшный вид чтобы я мог это упаковать в либу и использовать по кайфу
ну тогда логично что после этого могут проскочить сообщения пока ты его уже не заблокируешь навсегда.
Не скажи, там суть в том что обновление статуса происходит 1 раз. Если бы я мог заменить асинк чтение на синхронное, шанс проскока был бы в половину меньше
кратко: В препроцессе - lock.acquire(), в постпроцессе lock.release(), главное чтобы лок lock тот же был Ещё на это дам ссылку, вдруг когда пригодится подсмотреть чтото если надумаешь локи для юзера например брать https://github.com/darksidecat/aiopriman
Я не понял по описанию, чем ему не подошёл asyncio.lock
не понял вопрос
Я не понял по описанию, зачем он свои примитивы запилил
это я а не он)
Ой, это ты darksidecat?
Да ) А свои примитивы я делал для решения 2х проблем: хранение ключа по которому берётся лок и нормальный доступ к приватным проперти. Необходимость хранения ключа возможно стоит пересмотреть. Возможно в своих примитивах и нет необходимости, нужно подумать 🤔 А стоп, вспомнил) Ещё нужно хранить служебную информацию как здесь: https://github.com/darksidecat/aiopriman/blob/a3b08c79b3de76c1ca2d2b69a26559ffdd1ddd84/aiopriman/sync_primitives/semaphore.py#L27-L28 Вот что называется два месяца не заглядывал в репу
как оказалось я провтыкал и не установил username в телеге и он уже занят 😢
А если ты имел ввиду зачем вообще либа нужна то: Хотел упростить работу с локами в слудующих случаях: Допустим мне в одном месте для тролллинга нужно брать локи для юзера тогда я беру их для ключа "{user_id}:{"throttling"}" В нескольких других местах тоже нужен лок к некоторому ресурсу, тогда я в этих местах беру лок для ключа "somekey_name" и это будет один и тот же лок. Дальше, если лок не заблокирован и нет в очереди ожидающих то лок будет удалён с хранилища. Вот это я правда не тестировал на накладные расходы на создание/удаление и имеет ли это хоть какой-то значимый профит, нужно будет проверить кстати )
Интересно, спасибо)
Обсуждают сегодня