<div dir="ltr">Надеюсь на то, что авторы модулей типо DBI будут реализовывать свои reconnect_after_fork , для того, что бы лишний раз не заморачиваться по поводу открытых коннектов. Как то так:)<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:26 | От: 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">А зачем?
<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>
> Первая версия: <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>
> на cpan?.
<br>
>
<br>
> И моё мнение по поводу этих модулей:
<br>
> Плюсы первой версии:
<br>
>
<br>
> Простой интерфейс - определяем в своём модуле две функции AFTER_FORK и
<br>
> AFTER_FORK_OBJ, в зависимости от ситуации и остальное зависит уже от того,
<br>
> кто использует модуль, - загрузил он его или нет.
<br>
> Однозначно живые объекты, и мы никак не влияем на время жизни объекта(Об
<br>
> этом ниже).
<br>
>
<br>
> Минусы:
<br>
>
<br>
> Скорость работы зависит от размера арены(можно ускорить перенеся всю логику
<br>
> в xs).
<br>
>
<br>
> Плюсы второй версии:
<br>
>
<br>
> Элементарная pure perl реализация.
<br>
> Скорость работы зависит от кол-ва колбэков.(Их явно меньше, чем sv в арене).
<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>
</p>
</blockquote></div>