Приложение MFC должно быть отзывчивым перед лицом потока событий

Question

У меня есть устаревшее приложение C ++, MFC, которое в настоящее время компилируется в VS2005.

Имеет несколько сокетных подключений, а также пользовательский интерфейс.

Сокеты завершаются в потоках, отличных от MFC, в этих фоновых потоках выполняется некоторая работа, затем в основную очередь MFC отправляется сообщение, чтобы основное приложение могло заметить и выполнить соответствующие действия. Обратите внимание, что для каждого полученного сокетом сообщения отправляется одно сообщение в основной поток.

Основной поток , выполняемый в результате, обычно занимает доли секунды.

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

Если мне удалось четко выразить свою проблему: какие-либо предложения по решению, такие, чтобы графический интерфейс оставался отзывчивым перед лицом большого количества этих событий?

Answer 1

Если вы хотите, чтобы графический интерфейс имел полный приоритет над работой сокетов, вы можете использовать CWinApp :: OnIdle для проверки работы над сокетами.

Answer 2

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

Answer 3

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

На типичном компьютере экран перерисовывается только с частотой 60 кадров в секунду, так что ничего более быстрого, чем можно надеяться, не будет иметь смысла. Для пользователя даже 60 FPS действительно имеют смысл только для чего-то порядка фильма.

Для типичных обновлений данных 10 FPS - это быстро - чтобы воспринимать даже так много, вам нужно объединить данные в несколько частей, которые легко понять, и избегать перезаписи любого существующего текста, чтобы он не просто превращался в нечитаемое размытие.

Answer 4

Мой собственный ответ - не бросайте ничего слишком сильно! :)

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

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

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

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