[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