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