Посылка сигнала между потоками сводится к помещению события в Qt-шную очередь сообщений. Вам без очереди все равно не обойтись, поэтому пока не вижу серьезных причин отказываться от Qt-шной. В будущем, при необходимости, вы всегда сможете сделать свою специальную очередь для этого. Но без дополнительных тестов, показывающих что тормозит именно она, я бы пока не дергался.
С этим-то всё ясно, об этом-то сейчас и думаю. В том числе и в этом топике
А вот как раскидываются задачи на отправку между потоками сендерами? Или у вас по потоку на клиента и всем передаются одинаковые
данные?
Нет, на клиента
не по потоку. Сетевые клиенты собраны в пулы, каждый пул обрабатывает один поток. Количество таких пулов пока задается вручную при старте сервера. Трафик,
постоянно и равномерно отправляемый на клиента, составляет: в худшем случае 1 МБ/с, в среднем - 256 кБ/с.
И как вы определили, что "в кому" впадает именно при отправке сигнала?
Периодически удаётся "попасть" на это место при запуске сервера из-под отладчика. Последнее разумное место в стеке до AV это как раз вызов сигнала. Но, повторюсь, вопрос до конца не исследован, может это не причина, а следствие.
/* И выбор Qt для решения этой задачи удивляет. Не очень понятно для чего он здесь. Ну это риторический вопрос.
*/
Не менее риторический ответ - по историческим причинам
. Фоново уже думаю о том, чтобы уйти в что-нибудь менее тяжёлое типа libuv или asio. Может ещё ZeroMQ. Но, там много всяких плюшек от Qt используется типа соединения с БД, логирование, сеть, QSettings, плагины, QSingleApplication и т.п. Не хотелось бы всё это заменять на набор разнородных костылей. В любом случае, делать это только ради того, чтобы гордо сказать, что у "меня на сервере нет Qt" не будем
.
А вот "со своей специальной очередью" - думаем.
