<p>А чем? Просто ведь тогда нам придётся каждый раз думать о времени жизни объекта. <br /><br />27.01.2016, 11:22, "Алексей Мышкин" <<a href="mailto:parserpro@gmail.com">parserpro@gmail.com</a>>:</p><blockquote> Мне второй вариант симпатечней.<br /><br /> 27 января 2016 г., 1:22 пользователь evgeniy <<a href="mailto:evgeniy@just4i.ru">evgeniy@just4i.ru</a>> написал:<br /><blockquote> Отправлено с Mi Phone<br /> ---------- Перенаправленное сообщение ----------<br /> От: evgeniy <<a href="mailto:evgeniy@just4i.ru">evgeniy@just4i.ru</a>> |<br /> Дата: 27 янв. 2016 г. 1:15 |<br /> Тема: Re: [Moscow.pm] Захотелось мне "хуков" после вызова fork. |<br /> Кому: Victor Efimov <<a href="mailto:victor@vsespb.ru">victor@vsespb.ru</a>>Копия:<br /><br /><blockquote> Один раз для первого варианта, да и для второго тоже. Добавляем в модуль например sub AFTER_FORK_OBJ{ } и как итог эта функция будет автоматически вызываться в чилде после форка, для объектов данного типа<br /><br /> Отправлено с Mi Phone<br /> 27 янв. 2016 г. 0:58 | От: Victor Efimov <<a href="mailto:victor@vsespb.ru">victor@vsespb.ru</a>> | Сообщение:<br /><br /><blockquote> так "кажный раз" когда они делают if $pid eq $$ им нужно заменить на<br /> "каждый раз" добавлять коллбэк<br /><br /> 27 января 2016 г., 0:55 пользователь evgeniy <<a href="mailto:evgeniy@just4i.ru">evgeniy@just4i.ru</a>> написал:<br /><blockquote> И так каждый раз? А так возможно будет из коробки, с самыми основными<br /> модулями.<br /><br /><br /> Отправлено с Mi Phone<br /> 27 янв. 2016 г. 0:49 | От: Victor Efimov <<a href="mailto:victor@vsespb.ru">victor@vsespb.ru</a>> | Сообщение:<br /><br /> А классический подход - запомнить pid, а потом его сверять - не устраивает?<br /><br /> 27 января 2016 г., 0:44 пользователь evgeniy <<a href="mailto:evgeniy@just4i.ru">evgeniy@just4i.ru</a>> написал:<br /><blockquote> Надеюсь на то, что авторы модулей типо DBI будут реализовывать свои<br /> reconnect_after_fork , для того, что бы лишний раз не заморачиваться по<br /> поводу открытых коннектов. Как то так:)<br /><br /><br /> Отправлено с Mi Phone<br /> 27 янв. 2016 г. 0:26 | От: Victor Efimov <<a href="mailto:victor@vsespb.ru">victor@vsespb.ru</a>> | Сообщение:<br /><br /> А зачем?<br /><br /> 27 января 2016 г., 0:18 пользователь Evgeniy Vansevich<br /> <<a href="mailto:evgeniy@just4i.ru">evgeniy@just4i.ru</a>> написал:<br /><blockquote> Приветствую всех! Буквально несколько часов назад захотелось иметь нечто,<br /> называемое child_callback.<br /> А именно: мы форкаемся, и после форка в чилдах автоматом вызывается некая<br /> функция, которая делает всю грязную работу за нас.<br /> Быстрый поиск сказал, что ничего похожего нет, и как итог сделал сам.<br /> Сделал 2 версии, первая версия после форка проходится по<br /> арене(Devel::Gladiator) и ищет функции AFTER_FORK(для пакетов) и<br /> AFTER_FORK_OBJ (для объектов). Которые потом и вызываются.<br /> И вторая версия, которая хранит в себе "колбэки" которые нужно вызвать<br /> после<br /> форка, колбэки из модулей сами напихиваем из модулей.<br /><br /> Первая версия: <a href="https://gist.github.com/kadavr/e46fa7380b610bbf095e">https://gist.github.com/kadavr/e46fa7380b610bbf095e</a><br /> Вторая версия: <a href="https://gist.github.com/kadavr/dbed30507eceb3509b22">https://gist.github.com/kadavr/dbed30507eceb3509b22</a><br /><br /> Сразу вопросы: Какая реализация вам больше нравится? и нужен ли такой<br /> модуль<br /> на cpan?.<br /><br /> И моё мнение по поводу этих модулей:<br /> Плюсы первой версии:<br /><br /> Простой интерфейс - определяем в своём модуле две функции AFTER_FORK и<br /> AFTER_FORK_OBJ, в зависимости от ситуации и остальное зависит уже от<br /> того,<br /> кто использует модуль, - загрузил он его или нет.<br /> Однозначно живые объекты, и мы никак не влияем на время жизни объекта(Об<br /> этом ниже).<br /><br /> Минусы:<br /><br /> Скорость работы зависит от размера арены(можно ускорить перенеся всю<br /> логику<br /> в xs).<br /><br /> Плюсы второй версии:<br /><br /> Элементарная pure perl реализация.<br /> Скорость работы зависит от кол-ва колбэков.(Их явно меньше, чем sv в<br /> арене).<br /><br /> Минусы<br /><br /> Так как мы используем колбэки, то всё что мы захватим то будет жить ровно<br /> до<br /> момента выхода.<br /> Или можно взять weaken и каждый раз проверять "валидность" ссылки.<br /><br /> Спасибо.<br /><br /><br /> --<br /> Moscow.pm mailing list<br /> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org/">http://moscow.pm.org</a><br /><br /></blockquote> --<br /> Moscow.pm mailing list<br /> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org/">http://moscow.pm.org</a><br /><br /><br /> --<br /> Moscow.pm mailing list<br /> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org/">http://moscow.pm.org</a><br /><br /></blockquote> --<br /> Moscow.pm mailing list<br /> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org/">http://moscow.pm.org</a><br /><br /><br /> --<br /> Moscow.pm mailing list<br /> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org/">http://moscow.pm.org</a><br /><br /></blockquote> --<br /> Moscow.pm mailing list<br /> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org/">http://moscow.pm.org</a></blockquote></blockquote><br /> --<br /> Moscow.pm mailing list<br /> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org/">http://moscow.pm.org</a></blockquote><br /> --<br /> С уважением,<br /> Мышкин Алексей.<br /><br /> ,--<br /> Moscow.pm mailing list<br /> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org/">http://moscow.pm.org</a></blockquote>