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