Симпатичен простотой. Про время жизни помнить - это чтобы не вызвать коллбэк из "отжившего" объекта? А если на такой коллбэк ref вызвать - что получим?
27 января 2016 г., 11:26 пользователь Evgeniy Vansevich <[email protected]> написал: > А чем? Просто ведь тогда нам придётся каждый раз думать о времени жизни > объекта. > > 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 > > -- С уважением, Мышкин Алексей.
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
