<div dir="ltr">И так каждый раз? А так возможно будет из коробки, с самыми основными модулями.<br>
</div><div dir="ltr"><br>
</div><div dir="ltr"><br>
</div><div class="wps_signature">Отправлено с Mi Phone</div><div class="wps_quotion">27 янв. 2016 г. 0:49 | От: Victor Efimov <victor@vsespb.ru> | Сообщение:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">А классический подход - запомнить pid, а потом его сверять - не устраивает? <br>
<br>
27 января 2016 г., 0:44 пользователь evgeniy <<a href="mailto:evgeniy@just4i.ru">evgeniy@just4i.ru</a>> написал: <br>
> Надеюсь на то, что авторы модулей типо 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>
>> Приветствую всех! Буквально несколько часов назад захотелось иметь нечто, <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>
>> в xs). <br>
>> <br>
>> Плюсы второй версии: <br>
>> <br>
>> Элементарная pure perl реализация. <br>
>> Скорость работы зависит от кол-ва колбэков.(Их явно меньше, чем sv в <br>
>> арене). <br>
>> <br>
>> Минусы <br>
>> <br>
>> Так как мы используем колбэки, то всё что мы захватим то будет жить ровно <br>
>> до <br>
>> момента выхода. <br>
>> Или можно взять weaken и каждый раз проверять "валидность" ссылки. <br>
>> <br>
>> Спасибо. <br>
>> <br>
>> <br>
>> -- <br>
>> <a href="http://Moscow.pm">Moscow.pm</a> 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>
> <a href="http://Moscow.pm">Moscow.pm</a> 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>
> <a href="http://Moscow.pm">Moscow.pm</a> 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>
<a href="http://Moscow.pm">Moscow.pm</a> 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>
</p>
</blockquote></div>