[Moscow.pm] Захотелось мне "хуков" после вызова fork.

[Victor Efimov]

так "кажный раз" когда они делают 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
>