А зачем?
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
