Russian Qt Forum
Октябрь 01, 2024, 02:41 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Russian Qt Forum > Forum > Qt > Работа с сетью > Многопоточный сервер. Зачем он?
Страниц: [1]   Вниз
« предыдущая тема следующая тема »
  Печать  
Автор Тема: Многопоточный сервер. Зачем он?  (Прочитано 6546 раз)
mcrads
Гость
« : Февраль 14, 2010, 22:00 »
И снова я =)

Вопрос таков. Многопоточный сервер - что это и с чем его едят? к хелпу просьба не слишком далеко отсылать - я понял что собственно это такое. вопрос в другом - в чем его плюшки, зачем это нужно и стоит ли его мастерить для максимум трех входящих подключений?
Записан
voronElf
Гость
« Ответ #1 : Февраль 15, 2010, 06:46 »
Если ты подключения обрабатываешь в основном потоке, то пока ты не обработаешь текущее подключение, ты не сможешь обрабатывать следующее. Вопрос в том, будут ли подключения одновременными (скорей всего да), и сколько времени требуется на обработку одного запроса клиентского и сколько времени второй клиент может ждать в очереди (еще вапрос как организовать обработку текущего запроса и очередь запросов одновременно в одном потоке). Даже если подключения максисмум 3, эти вапросы все-равно надо решать. Идея многопоточного сервера избавляет от массы проблемок. А если сейчас у тебя максимум 3 подключения, не факт что через полгода из не будет 300.
Записан
sne
Гость
« Ответ #2 : Февраль 15, 2010, 08:40 »
Сколько я не работал с сетью в кьют, а работал я не много, мне показалось что тут практически все асинхронное, включая сокеты. Для эмуляции блокирующих сокетов используются функции waitFor... Так собственно вот, смысл изобретать велосипед, да еще и на трех подключениях, когда тот же Apache упрекают в использовании потоков для обработки своих подключений, и на его место, под фронтенд используют, к примеру, более экономичный по ресурсам ngix.

Я считаю что лучше оставить всю работу асинхронной, как есть. Если обрабатываемых данных много и из-за их обработки будет подвисать GUI, имеет смысл всю обработку будет просто перетащить в отдельный поток, все равно не создавая на каждое подключение своего.
Записан
voronElf
Гость
« Ответ #3 : Февраль 15, 2010, 09:06 »
Так асинхронность реализуется как раз через многопоточность. Объект отрабатывает асинхронную операцию в отдельном потоке, сообщая сигналами о результатах работы.

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

PS: ngix разве не многопоточный ? Экономия по ресурсам - эт зависит от того как код пишется.
Записан
BRE
Гость
« Ответ #4 : Февраль 15, 2010, 10:21 »
Цитата: voronElf от Февраль 15, 2010,  09:06
Так асинхронность реализуется как раз через многопоточность. Объект отрабатывает асинхронную операцию в отдельном потоке, сообщая сигналами о результатах работы.
Нет. Используется механизм не блокируемых сокетов. В цикле обработки сообщений проверяется появились ли данные для сокета, и если да - то вызывается его слот readyRead. Все это происходит в том же потоке, которому принадлежит сокет. Если в этом слоте производить продолжительные операции, то остановиться весь поток.
Поэтому, при таком подходе, необходимо минимизировать время нахождения в этом слоте, для того что бы не блокировать другие соединения.

Цитата: voronElf от Февраль 15, 2010,  09:06
PS: ngix разве не многопоточный ?
Нет. Он, как раз использует этот механизм. На многопроцессорной платформе могут быть запущено несколько worker-процессов, например по количеству процессоров.
« Последнее редактирование: Февраль 15, 2010, 10:23 от BRE » Записан
voronElf
Гость
« Ответ #5 : Февраль 15, 2010, 11:26 »
О как.  Шокированный
Молчу, каюсь, лезу в доки ...
Записан
mcrads
Гость
« Ответ #6 : Февраль 15, 2010, 20:48 »
Спасибо, будем пробовать =)
Я тоже против многопоточности - наворачивать много.
Записан
Страниц: [1]   Вверх
  Печать  
« предыдущая тема следующая тема »
 
Перейти в:  


Страница сгенерирована за 0.048 секунд. Запросов: 20.