2 паралельных сервера

А как ты из одного сокета двумя процессами собрался читать? Особенно с TCP. ЕМНИП там будет следующий кусок данных доставаться случайному процессу, одному а не обоим.

Если действительно надо вдвоем работать, сделай три процесса:
1. рабочий #1
2. рабочий #2
3. "Разветвитель", который получает команды из сети и передает рабочим.

разветвитель должен работать либо на тредах, либо асинхронно,чтоб один задумавшийся рабочий не поставил его в ступор.

еще- у тебя рабочие какой-то ответ клиенту посылают? Клиент ожидает два ответа или один?

>А как ты из одного сокета двумя процессами собрался читать? Особенно с TCP. ЕМНИП там будет следующий кусок данных доставаться случайному процессу, одному а не обоим.

У меня для каждого процесса открыто по сокету

>еще- у тебя рабочие какой-то ответ клиенту посылают? Клиент ожидает два ответа или один?

В принципе да,но это не принципиально.Так что этот аспект можно опустить

> У меня для каждого процесса открыто по сокету

То есть у каждого процесса - свой сокет. И другой сокет он не трогает.

Объясни тогда еще раз, в чем проблема ? Процесс A доходит до вызова recv() и там подвисает - это ж нормальное поведение блокирующего сокета. Ждем данных.

>Процесс A доходит до вызова recv() и там подвисает - это ж нормальное поведение блокирующего сокета. Ждем данных.

Согласен.Процесс А виснет на recv.Если в это время,я подключаюсь по UDP,то Процесс Б ничего не получит.А мне надо,чтобы он получил данные. Другими словами мне не надо,что бы он вис там.

> Согласен.Процесс А виснет на recv.Если в это время,я подключаюсь по UDP,то Процесс Б ничего не получит.А мне надо,чтобы он получил данные. Другими словами мне не надо,что бы он вис там.

Если А, оперируя с сокетом s1, тормозит Б, который этот сокет не трогает - то это действительно очень странно. Не должно быть такого.

* Посмотри, в чем именно висит Б (gdb'ой например подключись) .

* сокеты создаются до форка или уже в детях? (по-моему разницы быть не должно, но интересно. если до форка - переставь чтобы создавало после)

так-с, для TCP вообще-то надо для начала bind-listen-accept сделать, а уже потом, когда к серверу кто-то подключился вызывать recv

>так-с, для TCP вообще-то надо для начала bind-listen-accept сделать, а уже потом, когда к серверу кто-то подключился вызывать recv

Ты забыл про socket,в начале.

Я думал, что про это всё нет смысла упоминать,т.к. я написал,что запускаю сервер,а это подразумевает socket-bind-listen-accept.

На какие конкретно порты подключены сокеты? Надеюсь не на один и тотже порт?

> Надеюсь не на один и тотже порт?

А почему бы и нет?

>На какие конкретно порты подключены сокеты? Надеюсь не на один и тотже порт?

Не вижу проблеммы,если будет на один и тот же порт,но нет.Не на один и тот же.5001 и 6001

Мне кажется, что исходя из сказанной информации нельзя найти ответ на проблему. Там может быть все что угодно. Может это примитивы синхронизации шалят?

Есть вариант использовать системный вызов poll и оба сервера обрабатывать в одном потоке. Тогда не будет геммороя с синхронизацией потоков, намного легче будет отлаживать и правильно написанная программа будет блокироваться только лишь в одном месте - poll().

Проблема решена.Решил не стучать головой об стенку, а обойти её.

Запустил оба сервера как 2 паралельных прилложения и всё работает.