Покурил мануалы, и беру свои слова обратно. Гарантии неделимости даются только для DGRAM-сокетов. В случае TCP возможна частичная передача. Задачка разработки протокола, где можно шарить одно соединение между несколькими процессами усложняется.
On Tue, Sep 8, 2015 at 2:33 PM Victor Efimov <[email protected]> wrote: > Вообще да. Нужен такой протокол и нужно опираться на гарантии ОС по > поводу атомарности и флаша буферов и их размера. Чего там с send? > === > If the message is too long to pass atomically through the underlying > protocol, the error EMSGSIZE is returned, and the message is not > transmitted > === > как оно будет если сервер не успевает читать данные? И какой размер > гарантируется? по-моему это не очень документировано > http://stackoverflow.com/a/16165686/1625053 > > 8 сентября 2015 г., 15:22 пользователь Alexander Lourier > <[email protected]> написал: > > Один сокет можно использовать в нескольких процессах, но у вас должен > быть > > протокол, который это поддерживает. Системный вызов 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 > > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org >
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
