Russian Qt Forum

И снова я =)

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

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

Сколько я не работал с сетью в кьют, а работал я не много, мне показалось что тут практически все асинхронное, включая сокеты. Для эмуляции блокирующих сокетов используются функции waitFor... Так собственно вот, смысл изобретать велосипед, да еще и на трех подключениях, когда тот же Apache упрекают в использовании потоков для обработки своих подключений, и на его место, под фронтенд используют, к примеру, более экономичный по ресурсам ngix.

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

Так асинхронность реализуется как раз через многопоточность. Объект отрабатывает асинхронную операцию в отдельном потоке, сообщая сигналами о результатах работы.

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

PS: ngix разве не многопоточный ? Экономия по ресурсам - эт зависит от того как код пишется.

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

Нет. Он, как раз использует этот механизм. На многопроцессорной платформе могут быть запущено несколько worker-процессов, например по количеству процессоров.

О как.  :o
Молчу, каюсь, лезу в доки ...

Спасибо, будем пробовать =)
Я тоже против многопоточности - наворачивать много.