История изменений
Исправление DRVTiny, (текущая версия) :
Вот вроде бы неплохая вещь, и отлично вписывается в архитектуру, которая итак вся на AnyEvent'е:
http://search.cpan.org/~salva/AnyEvent-Semaphore-0.01/lib/AnyEvent/Semaphore.pm
Но... Мне не нужно ничего ждать, если семафор с size=1 (ИМХО, mutex) «внезапно занят»! Мне нужно просто понять, что «занят» - и пойти себе восвояси.
У меня запускается кусок кода, создающий приличную нагрузку на память, базы данных мучающий, считающий по результатам всего этого кеш, из которого потом уже веб-приложение достанет свои данные быстро и весело.
И теперь представьте себе: запустился один такой кусок кода на «регулярной основе». Потом кто-то запустил тот же самый кусок кода из CLI или из «Админки» (на нерегулярной основе). Одно с другим пересеклось, что плохо конечно. И вот тот кусок кода, который из админки толкнули, терпеливо ждёт на семафоре, дожидается... и начинает снова люто терзать память, базу данных (там ещё в самой базе проходит транзакция, так что одновременно в памяти СУБД существуют две копии - «старая», которую она отдаёт клиентам и «новая», радикально изменённая, которая формируется в рамках транзакции), что-то считает... Это при том, что реальная разница в том, ЧТО отправится в кеш между соседними запусками - просто никакая.
В принципе можно наверное исключить повторные запуски именно данного куска кода записью «метки последнего обновления» в кеше (благо, в том же Redis есть операции getset), но... подход уж больно не универсальный и основан просто на том, что «нам нельзя чаще, чем раз в 5 минут, вот нельзя - и всё тут».
Ммм... Есть мысль писать в SCALAR в SharedMemory метку последнего обновления. Тогда и волки будут сыты (можно делать LOCK_NB этого скаляра, и если не удалось залочить - выходить), и овцы целы (я получил лок, посмотрел что там записано, увидел, что времени маловато прошло с прошлого запуска - разлочил и ушёл восвояси ).
Коллеги, как вам последний подход? Или всё-таки писать сие в файлик и делать на нём flock кошернее?
Исходная версия DRVTiny, :
Вот вроде бы неплохая вещь, и отлично вписывается в архитектуру, которая итак вся на AnyEvent'е:
http://search.cpan.org/~salva/AnyEvent-Semaphore-0.01/lib/AnyEvent/Semaphore.pm
Но... Мне не нужно ничего ждать, если семафор с size=1 (ИМХО, mutex) «внезапно занят»! Мне нужно просто понять, что «занят» - и пойти себе восвояси.
У меня запускается кусок кода, создающий приличную нагрузку на память, базы данных мучающий, считающий по результатам всего этого кеш, из которого потом уже веб-приложение достанет свои данные быстро и весело.
И теперь представьте себе: запустился один такой кусок кода на «регулярной основе». Потом кто-то запустил тот же самый кусок кода из CLI или из «Админки» (на нерегулярной основе). Одно с другим пересеклось, что плохо конечно. И вот тот кусок кода, который из админки толкнули, терпеливо ждёт на семафоре, дожидается... и начинает снова люто терзать память, базу данных (там ещё в самой базе проходит транзакция, так что одновременно в памяти СУБД существуют две копии - «старая», которую она отдаёт клиентам и «новая», радикально изменённая, которая формируется в рамках транзакции), что-то считает... Это при том, что реальная разница в том, ЧТО отправится в кеш между соседними запусками - просто никакая.
В принципе можно наверное исключить повторные запуски именно данного куска кода записью «метки последнего обновления» в кеше (благо, в том же Redis есть операции getset), но... подход уж больно не универсальный и основан просто на том, что «нам нельзя чаще, чем раз в 5 минут, вот нельзя - и всё тут».