Один сокет можно использовать в нескольких процессах, но у вас должен быть протокол, который это поддерживает. Системный вызов send позволяет отправлять цельные блоки данных так, чтобы они не перебивались в середине данными из другого процесса. Например, я вполне могу представить себе родительский процесс, который устанавливает соединение с получателем данных, запускает N детей, которые что-то вычисляют и сбрасывают результаты своей работы непосредственно в сокет. Если нужно отправлять запросы и получать ответы, то тут уже никак не проверить, кому из процессов достанется ответ, если они друг с другом не будут договариваться через какие-то механизмы синхронизации. Тогда дочерний процесс должен закрыть соединение и открыть своё новое, чтобы с тем же сервером общаться по отдельному соединению.
On Tue, Sep 8, 2015 at 1:59 PM Victor Efimov <[email protected]> wrote: > 8 сентября 2015 г., 14:52 пользователь Ilya Chesnokov > <[email protected]> написал: > > 8 сентября 2015 г., 0:03 пользователь Victor Efimov <[email protected]> > написал: > >> Я думаю имелось ввиду несколько другое. Примеры это DBI и CPAN Redis. > > > > Ну да. Хотя в целом про TCP keepalive тоже интересная тема. > > > >> 1) Прежде чем послать данные в сокет сделать следующее: > >> > >> if ($self->{pid} != $$) { > >> $self->connect; > >> } > >> > >> (код из Redis.pm) > >> > >> 2) В DESTROY, если он есть, делать деструкцию только если $self->{pid} > == $$. > >> Надо сказать, это нужно только в DBI, т.к. он в DESTROY посылает > >> какие-то данные в сокет. В "обычных" клиентах не нужно. В Redis.pm > >> нету. > > > > В-общем, ключевой вопрос в том, можно ли использовать одно и то же > > соединение в разных процессах, если я правильно понял. > > Если нельзя, то первый подход используется, если нельзя, то второй - > > не закрывать соединение в дочерних процессах, а только в родительском. > > По-моему одно и то же соединение в любом случае использовать нельзя. > Учитывая что сценарий - > это fork() про который мы не знаем зачем и почему он. Возможно до > fork() кто-то использовал соединение, после fork() > собирается использовать и в child и parent. В таком случае и child и > parent будут писать в один сокет. Это всё равно что они по-очереди > будут писать в сокет в одном процессе. > > А DESTROY в DBI имхо просто для того чтобы закрыть коннект, чтобы у > mysql сервера не висели открытые коннекты > > > > >> 3) реконнект > >> > >> 8 сентября 2015 г., 5:36 пользователь Eugen Konkov <[email protected]> > написал: > >>> Здравствуйте, Ilya. > >>> > >>> IC> Есть ли готовые модули для поддержания постоянного соединения с > >>> IC> каким-либо сервером? > >>> Обычное TCP соединение с keep-alive пакетами > >>> http://habrahabr.ru/company/intersystems/blog/155565/ > >>> http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html > >>> > >>>>не закрывалось при уничтожении форка > >>> Делаете управление соединениями в мастер процессе. Создали соединение > или их pool и отдаёте fork'ам хендлы. Если будет один хендл, То нужно будер > решить проблему, какому форку передавать пришедший ответ (Думаю будет проще > если создавать хендл/fork) > >>> > >>> Вы писали 7 сентября 2015 г., 12:18:21: > >>> > >>> IC> Добрый день. > >>> > >>> IC> Есть ли готовые модули для поддержания постоянного соединения с > >>> IC> каким-либо сервером? Нужно для того, например, чтобы > инициализировать > >>> IC> соединение при старте веб-приложения и повторно использовать в > форках, > >>> IC> при этом чтобы оно не закрывалось при уничтожении форка, ну и > заново > >>> IC> соединялось при необходимости. > >>> > >>> IC> В-общем, нужно что-то вроде той части DBI, которая отвечает за > >>> IC> TCP-соединение, но без всего того, что связано непосредственно с > >>> IC> базами данных. > >>> > >>> IC> Да, и еще интересно, есть ли что-то подобное отдельно для > AnyEvent::Handle. > >>> > >>> IC> -- > >>> IC> Best regards, > >>> IC> Ilya Chesnokov > >>> > >>> > >>> > >>> -- > >>> С уважением, > >>> Eugen mailto:[email protected] > >>> > >>> -- > >>> Moscow.pm mailing list > >>> [email protected] | http://moscow.pm.org > > > > > > > > -- > > Best regards, > > Ilya Chesnokov > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org >
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
