AM
Один ресурс на тачке, на которой гуникорн.
Size: a a a
2019 November 22
БС
то есть проблема не в thread.local а в самом lock.
AM
тогда лок надо тоже внешний 😊
Лок тоже внешний, а вот флаг поймал ты Лок или нет - локальная проблема.
БС
Что значит внешний? Что именно?
AM
Говорю ж что нужен флаг, на то что выше по call stack кто-то его уже поймал.
БС
у тебя оба процесса будут копиями..
AM
Что значит внешний? Что именно?
Лок файл с fcntl exclusive
БС
запиши в этот файл pid процесса который взял лок.
БС
хотя я не работал с fcntl..
БС
В общем тебе в лок надо внести именно PID и по нему проверять
БС
хоть в thread.local добавь текущий PID
KK
Есть вариант так не делать, при условии что процесс форка я контролировать не могу. Его будет делать waitress или gunicorn.
Проблема, которую я хочу создать:
- есть несколько публичных функций модуля.
- они могут вызывать друг друга внутри себя
- пользователь может вызывать любую из функций
- надо написать декоратор для этих функций, который реализует Лок на ресурс.
- функции вложенные должны уметь получить Лок захваченный в этом же треде выше по колл стэку
- сейчас это делается пропагированием аргумента skip lock при вызове вложенных функций.
Хочу реализовать без аргумента.
Проблема, которую я хочу создать:
- есть несколько публичных функций модуля.
- они могут вызывать друг друга внутри себя
- пользователь может вызывать любую из функций
- надо написать декоратор для этих функций, который реализует Лок на ресурс.
- функции вложенные должны уметь получить Лок захваченный в этом же треде выше по колл стэку
- сейчас это делается пропагированием аргумента skip lock при вызове вложенных функций.
Хочу реализовать без аргумента.
Очень похоже на то, что я делал с помощью пакета xlocal. Надо было с помощью контекстного менеджера менять настройки поведения кода, который будет выполняться ниже по стеку. Конкретно - надо было запрещать или разрешать "райзить" сигналы (паттерн обсервер). Но у меня не было проблем с форками - у меня всё форкалось заранее, сразу после создания wsgi приложения, но до первого запроса.
AM
Очень похоже на то, что я делал с помощью пакета xlocal. Надо было с помощью контекстного менеджера менять настройки поведения кода, который будет выполняться ниже по стеку. Конкретно - надо было запрещать или разрешать "райзить" сигналы (паттерн обсервер). Но у меня не было проблем с форками - у меня всё форкалось заранее, сразу после создания wsgi приложения, но до первого запроса.
О, мьют) Киллер фича всегда.
KK
С локами через монгу кстати по моему тоже делал то подобное - если код ниже по стеку просил уже захаванный в треде лок, то он его получал. Но сейчас не могу найти это - не пригодилось и потому выпилили
KK
Если получение pid-а процесса не очень дорогая операция, то можно треад-локал завязать на этот pid, что бы не "видеть" данные другого процесса
KK
Как мне кажется, в новых питонах вместо xlocal можно использовать ContextVar. Оно хотя бы лучше дружит с асинхронкой
n
Разбудите меня через сто лет и спросите, что обсуждают в рантсе, и я отвечу - спорят про вим и емакс, винду или линукс, а также обсуждают увлажнители воздуха
AG
Разбудите меня через сто лет и спросите, что обсуждают в рантсе, и я отвечу - спорят про вим и емакс, винду или линукс, а также обсуждают увлажнители воздуха
Жизненные темы
AM
Разбудите меня через сто лет и спросите, что обсуждают в рантсе, и я отвечу - спорят про вим и емакс, винду или линукс, а также обсуждают увлажнители воздуха
И второй питон!
ЕЧ
А как же машин лёрнинг и вот это всё?)