Привет. Прокоментируйте плиз. Я считаю, что с одной стороны при написании сервера нельзя выделять на каждое подключение по 1-2 потока, потому что это лишние ресурсы. С другой стороны нельзя писать всё в 1 потоке, потому что много многопроцессоров - не редкость.
Вывод: надо делать пул потоков, размером x*cpucount, у каждого потока есть свой массив сокетов, который передается в функцию select(). При этом слушающий сокет находится во всех массивах, а остальные сокеты каждый в своем, чтобы не пришлось синхронизировать.

Завист на сколько клиентов расчитан сервер.

Если к примеру планируется клиентов 200-300, то можно без опасения делать один поток на одного клиента

leniviy, я всегда использую пул потоков. где кол-во потоков равно кол-ву ядер. проблем не замечал.


к чему такой изврат?

Это не изврат, а самый простой способ работать с несколькими клиентами.

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

К томуже можно использовать пул потоков, не по количеству ядер, а по количеству предпологаемых клиентов.

потому и изврат.


он оправдан только тогда, когда хочется что-то по быстрому на###кодить  
с точки зрения архитектуры такого сервера - она изначально в тупике.


но это уже верх изврата из всех извратов  

Если можно написать сервер выполняющий свои задачи за 1 день, зачем на него тратить 3 дня, кто оплатит 2 дня разницы ?

Если есть время экперементировать и добиться техже результатов, но более изящно - ваше право.

меня бы совесть загрызла за то, что написал такое Гэ..

Добавлено через 4 минуты и 58 секунд
тема уже закрыта, оказывается  

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

И самое узкое место в нем - это работа с БД, которая тратит намного больше ресурсов чем переключение/создание потоков.

тысяча - это очень мало

Одновременно?
Количество виртуальной памяти, резервируемой для начального стека потока по умолчанию равно 0x100000 - 1048576 б + память для кучи + еще что.....
Т.е. 100 клиентов - это примерно 100 Мб оперативки - только на системное обслуживание потоков
1000 клиентов - уже гигабайт......
А еще 1000 буферов приема/передачи в модуле TCP?
Так что один клиент один поток и одновременно 1000 клиентов - накладно.....
Потому эту модель и ругают.....



Это сообщение отредактировал(а) Олег2005 - 2.11.2010, 23:14

гигабайт

Кстати у меня есть маленький однопоточный шлюз Bluetooth->TCP . Когда я его кодил, оказалось, что всё не так просто.
На каждое соединение пришлось выделять структурку ака job с полем state, счетчиками и 2 FIFO буферами.
Пришлось добавлять switch(state)/case , чтобы резюмить прерванную передачу.
Все эти структурки лежат в мапе, и когда select() возвращает готовые к работе сокеты, они ищутся в этой мапе

Пардон.
Ошибся