Изначально так и планировалось, чтобы на 1 запрос 1 поток... Но суть в чем. Имеется система для передачи больших объемов информации (обновления данных по сети). Причем данные могут быть разнотипными (с разными приоритетами). В итоге имеем большое число возможных одновременных подключений. Если создавать отдельные потоки для каждого соединения, то их может стать слишком много и передача "умрет", будет разом обновляться у всех, но ОЧЕНЬ медленно (не из-за сети, так из-за скорости чтения с жесткого диска). Поэтому было принято решение создать заранее ограниченное количество потоков, а все запросы от клиентов распределять между ними, но не просто так, а на передачу 1 файла, т.е. клиент подключился и попал в очередь. Дошла очередь до него - сокет отправлен в поток, передается ОДИН файл и сокет попадает обратно в очередь, а потоку передают следующий. Так сделано из-за приоритетов... Если давать возможность загружать сразу все файлы, то просто приоритетные запросы файлов, необходимых срочно, будут ждать очень долго... А если создавать по одному потоку на передачу одного файла одному клиенту - это будет глупо, по-моему..

З.Ы. нагорожено там из-за некоторых дополнительных требований, они тут ни при чем)))



Я не могу отдавать сокет обрабатывающему потоку, ибо потом он возвращается в главный и может быть передан затем другим... А вот насчет передачи сигналов - если так получится, то будет круто, надо попробовать)))

Задача потока выполнять долгую операцию на фоне позволяя работать пользователю без блокировки интерфейса. Если сокет будет находится в главном потоке да еще и write() использовать, то какой смысл в отдельном потоке? write() и read() неблокирующие методы и возвращаются моментально.

Предположим, что у нас иная ситуация. На каждого клиента запускается блокирующая функция, которая производит долгие вычисления, а потом результат шлет в сокет. В этом случае нам уже нужны отдельные потоки. Задача клиента сказать потоку "посчитай мне что-то в отдельном потоке, а потом верни результат в главный поток, чтобы я мог их передать".

Если в твоем варианте такая блокирующая функция - чтение файла с диска в буффер, то файл должен читаться в отдельном потоке, формировать буффер с данными, а потом сообщать (эмитить) в основной поток, что данные готовы, типа забирай.

Сообщение отредактировал SABROG - 19.2.2010, 13:47

Вот я и думал об этом как раз, чтобы обрабатывающие потоки просто главному пересылали массивы информации, считанной из файла, а он уже отсылал...

OrSOn, я скоро приеду домой и сброшу тебе пример асинхронной передачи. Т.е. в момент когда сокет сможет принять данные будет генерировать сигнал, в слоте которого будет отправляться небольшой блок данных с последующем выходом из слота. При следующем проходе, опять сигнал, отправка, выход... Пока все данные не будут переданы.

Возможно, все равно придется использовать пул потоков. В Qt уже есть их реализация, посмотри на QThreadPool и QRunnable.

Ок, спасибо, буду ждать)

Думаю вместо того, чтобы данные передавать с сигналом можно использовать кольцевой буффер (circular buffer, ring buffer). Можно посмотреть как он реализован в Wait Conditions Example.

А если принимающая сторона (клиент) сидит на узком канале и не успевает выбирать данные, которые ему пихают.

OrSOn
Вот новый архив, асинхронный сервер лежит в server-async. Для работы используется QSocketNotifier.

Сообщение отредактировал BRE - 19.2.2010, 15:36

В общем QIODevice и так использует QRingBuffer (internal class), поэтому можно просто завести буфер на базе QByteArray для каждого сокета, ловить сигнал bytesWritten() и просить (emit signal) поток подгрузить новую порцию данных, если клиенту были отправлены все данные. Поток сам очистит буффер и поместит следующий блок, затем оповестит (emit signal) об этом сокет. Сокет уже их будет писать, а поток продолжит читать данные из файлов для других сокетов и эмитить им сигналы как прочитает.

Я немного про другое... Qt-сокеты кешируют отправляемые данные. Если же из-за каких-то проблем с сетью или низкой скорости работы принимающей стороны, реально данные по сети не уходят (буфер отправки tcp-стека переполнен), то они будут скапливаться в памяти. А сервер вместо того, что бы заниматься теми клиентами, которые готовы принимать данные, будет периодически загружать все новые куски для "тормозящего" клиента и складывать их в памяти.

Хотя... Если bytesWritten отправляется только после реальной отправки данных, то все будет нормально. Полез смотреть.

Да, вместо QSocketNotifier можно использовать сигнал bytesWritten().


Сообщение отредактировал BRE - 19.2.2010, 17:10

Спасибо, сейчас буду пробовать все посоветованное..))