[Moscow.pm] Захотелось мне "хуков" после вызова fork.
Evgeniy Vansevich
evgeniy на just4i.ru
Ср Янв 27 00:54:40 PST 2016
CODE? :)
27.01.2016, 11:45, "Алексей Мышкин" <parserpro на gmail.com>:
> Симпатичен простотой.
> Про время жизни помнить - это чтобы не вызвать коллбэк из "отжившего" объекта?
> А если на такой коллбэк ref вызвать - что получим?
>
> 27 января 2016 г., 11:26 пользователь Evgeniy Vansevich <evgeniy на just4i.ru> написал:
>> А чем? Просто ведь тогда нам придётся каждый раз думать о времени жизни объекта.
>>
>> 27.01.2016, 11:22, "Алексей Мышкин" <parserpro на gmail.com>:
>>> Мне второй вариант симпатечней.
>>>
>>> 27 января 2016 г., 1:22 пользователь evgeniy <evgeniy на just4i.ru> написал:
>>>> Отправлено с Mi Phone
>>>> ---------- Перенаправленное сообщение ----------
>>>> От: evgeniy <evgeniy на just4i.ru> |
>>>> Дата: 27 янв. 2016 г. 1:15 |
>>>> Тема: Re: [Moscow.pm] Захотелось мне "хуков" после вызова fork. |
>>>> Кому: Victor Efimov <victor на vsespb.ru>Копия:
>>>>
>>>>> Один раз для первого варианта, да и для второго тоже. Добавляем в модуль например sub AFTER_FORK_OBJ{ } и как итог эта функция будет автоматически вызываться в чилде после форка, для объектов данного типа
>>>>>
>>>>> Отправлено с Mi Phone
>>>>> 27 янв. 2016 г. 0:58 | От: Victor Efimov <victor на vsespb.ru> | Сообщение:
>>>>>
>>>>>> так "кажный раз" когда они делают if $pid eq $$ им нужно заменить на
>>>>>> "каждый раз" добавлять коллбэк
>>>>>>
>>>>>> 27 января 2016 г., 0:55 пользователь evgeniy <evgeniy на just4i.ru> написал:
>>>>>>> И так каждый раз? А так возможно будет из коробки, с самыми основными
>>>>>>> модулями.
>>>>>>>
>>>>>>> Отправлено с Mi Phone
>>>>>>> 27 янв. 2016 г. 0:49 | От: Victor Efimov <victor на vsespb.ru> | Сообщение:
>>>>>>>
>>>>>>> А классический подход - запомнить pid, а потом его сверять - не устраивает?
>>>>>>>
>>>>>>> 27 января 2016 г., 0:44 пользователь evgeniy <evgeniy на just4i.ru> написал:
>>>>>>>> Надеюсь на то, что авторы модулей типо DBI будут реализовывать свои
>>>>>>>> reconnect_after_fork , для того, что бы лишний раз не заморачиваться по
>>>>>>>> поводу открытых коннектов. Как то так:)
>>>>>>>>
>>>>>>>> Отправлено с Mi Phone
>>>>>>>> 27 янв. 2016 г. 0:26 | От: Victor Efimov <victor на vsespb.ru> | Сообщение:
>>>>>>>>
>>>>>>>> А зачем?
>>>>>>>>
>>>>>>>> 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 mailing list
>>>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>>>
>>>>>>>> --
>>>>>>>> Moscow.pm mailing list
>>>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>> --
>>>>>>> Moscow.pm mailing list
>>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>>
>>>>>>> --
>>>>>>> Moscow.pm mailing list
>>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>> --
>>>>>> Moscow.pm mailing list
>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>
>>>> --
>>>> Moscow.pm mailing list
>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>
>>> --
>>> С уважением,
>>> Мышкин Алексей.
>>>
>>> ,--
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>
> --
> С уважением,
> Мышкин Алексей.
>
> ,--
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
Подробная информация о списке рассылки Moscow-pm