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