Поток ввода очереди

Question

Что такое «очередь ввода потока»? Я видел это упомянутое в MSDN несколько раз и может перестать задаваться вопросом, является ли это просто очередью сообщений для окна, которая создается потоком, который они имеют в виду, или чем-то еще.

Пример:

Хук WH_MOUSE_LL позволяет вам контролировать события ввода мыши о для публикации в очереди ввода потока .

Answer 1

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

Согласно MSDN , сообщения ввода с клавиатуры и мыши отправляются в очередь сообщений потока, связанного с соответствующим окном. Поэтому я считаю, что «очередь ввода потока» - это просто еще один способ сказать «очередь сообщений потока».

РЕДАКТИРОВАТЬ: Раймонд указал (см. Комментарии), что ввод может быть перенаправлен в очередь сообщений другого потока, используя функцию AttachThreadInput. Таким образом, «очередь ввода потока» означает, какая очередь сообщений получает ввод для данного потока; по умолчанию это очередь сообщений того же потока, но это может быть очередь сообщений для другого потока.

Answer 2

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

Да, есть два набора сообщений. Существует «очередь сообщений» и «очередь входных сообщений». Последний содержит список необработанных событий сообщений мыши и клавиатуры. Первый содержит опубликованные и обобщенные сообщения.

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

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

GetMessage() обрабатывает их отдельно.

THREADINFO содержит указатель непосредственно на список / очередь сообщений. Это сканируется, если установлен QS_POSTMESSAGE.

Если установлены статуи очереди QS_INPUT или QS_EVENT, список / очередь входных данных сканируется путем получения исходного указателя структуры очереди из THREADINFO, а затем указателя на список ввода из этой структуры очереди. Странно, я знаю.

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

Другие синтезированные сообщения работают аналогично в том смысле, что они основаны на данных, хранящихся вне фактических списков сообщений очереди, но все еще «в» других данных в самих структурах очереди.