[Moscow.pm] Захотелось мне "хуков" после вызова fork.

Victor Efimov victor на vsespb.ru
Вт Янв 26 13:26:27 PST 2016


А зачем?

27 января 2016 г., 0:18 пользователь Evgeniy Vansevich
<evgeniy на just4i.ru> написал:
> Приветствую всех! Буквально несколько часов назад захотелось иметь нечто,
> называемое 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
> moscow-pm на pm.org | http://moscow.pm.org
>


Подробная информация о списке рассылки Moscow-pm