{"id":4153,"date":"2013-06-06T07:00:00","date_gmt":"2013-06-06T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2013\/06\/06\/a-pathological-program-which-ignores-the-keyboard-and-understanding-the-resulting-behavior-based-on-what-we-know-about-the-synchronous-input\/"},"modified":"2013-06-06T07:00:00","modified_gmt":"2013-06-06T07:00:00","slug":"a-pathological-program-which-ignores-the-keyboard-and-understanding-the-resulting-behavior-based-on-what-we-know-about-the-synchronous-input","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20130606-00\/?p=4153","title":{"rendered":"A pathological program which ignores the keyboard, and understanding the resulting behavior based on what we know about the synchronous input"},"content":{"rendered":"

Today, we’ll illustrate the consequences of\n\nthe way the window manager synchronizes input<\/A>\nwhen two or more threads\ndecide to share an input queue.\n<\/P>\n

\nSince I need to keep separate state for the two windows,\nI’m going to start with the\n\nnew scratch program<\/A>\nand\nmake the following changes:\n<\/P>\n

\n#include <strsafe.h><\/FONT><\/p>\n
class RootWindow : public Window\n{\npublic:\n virtual LPCTSTR ClassName() { return TEXT(“Scratch”); }\n static RootWindow *Create();<\/p>\n
 void AppendText(LPCTSTR psz)\n {\n  ListBox_SetCurSel(m_hwndChild,\n                    ListBox_AddString(m_hwndChild, psz));\n }<\/p>\n
 void LogMessage(const MSG *pmsg)\n {\n   TCHAR szMsg[80];\n   StringCchPrintf(szMsg, 80, TEXT(“%d\\t%04x\\t%p\\t%p”),\n                   pmsg->time,\n                   pmsg->message,\n                   pmsg->wParam,\n                   pmsg->lParam);\n   AppendText(szMsg);\n}<\/FONT><\/p>\n
protected:\n LRESULT HandleMessage(UINT uMsg, WPARAM wParam, LPARAM lParam);\n LRESULT OnCreate();\nprivate:\n HWND m_hwndChild;\n};<\/p>\n
LRESULT RootWindow::OnCreate()\n{\n m_hwndChild = CreateWindow(\n      TEXT(“listbox”), NULL,\n      LBS_HASSTRINGS | LBS_USETABSTOPS |\n      WS_CHILD | WS_VISIBLE | WS_TABSTOP | WS_VSCROLL,\n      0, 0, 0,0, GetHWND(), (HMENU)1, g_hinst, 0);<\/p>\n
 return 0;\n}<\/FONT>\n<\/PRE>\n
\nAll we did above was add a list box to the window and provide\npublic methods\nAppend­Text<\/CODE> to add a string to the list box\nand\nLog­Message<\/CODE> that adds a string based on the\ncontents of a MSG<\/CODE> structure.\nWe’re going to use this list box to log what the program is doing.\n<\/P>\n
\nbool ShouldLogMessage(UINT uMsg)\n{\n if (uMsg >= WM_KEYFIRST && uMsg <= WM_KEYLAST) return true;\n if (uMsg >= WM_MOUSEFIRST && uMsg <= WM_MOUSELAST) return true;\n return false;\n}<\/FONT>\n<\/PRE>\n
\nThis helper function above tells us which messages we want to log.\nFor now, let’s log keyboard and mouse messages.\n<\/P>\n
\nNow, in order to demonstrate input thread attachment,\nwe need two threads.\nHere comes the second thread:\n<\/P>\n
\nDWORD CALLBACK AttachedThreadProc(void *lpParameter)\n{\n RootWindow *prw = RootWindow::Create();\n SetWindowText(prw->GetHWND(), TEXT(“Bad window”));\n AttachThreadInput(PtrToInt(lpParameter),\n                   GetCurrentThreadId(), TRUE);\n ShowWindow(prw->GetHWND(), SW_SHOW);<\/p>\n
 BOOL fIgnoreKeyboard = FALSE;<\/p>\n
 while (true) {\n  MSG msg;\n  BOOL fMessage;\n  if (fIgnoreKeyboard) {\n   fMessage =\n    PeekMessage(&msg, NULL, 0, WM_KEYFIRST – 1, PM_REMOVE) ||\n    PeekMessage(&msg, NULL, WM_KEYLAST + 1, 0xFFFFFFFF, PM_REMOVE);\n  } else {\n   fMessage = PeekMessage(&msg, NULL, 0, 0, PM_REMOVE);\n  }<\/p>\n
  if (!fMessage) { WaitMessage(); continue; }<\/p>\n
  if (msg.message == WM_QUIT) break;<\/p>\n
  if (ShouldLogMessage(msg.message)) {\n   prw->LogMessage(&msg);\n  }<\/p>\n
  if (msg.message == WM_KEYDOWN && msg.wParam == VK_SHIFT) {\n   prw->AppendText(TEXT(“Stop processing keyboard messages”));\n   fIgnoreKeyboard = TRUE;\n  }<\/p>\n
  TranslateMessage(&msg);\n  DispatchMessage(&msg);\n }\n AttachThreadInput(PtrToInt(lpParameter),\n                   GetCurrentThreadId(), FALSE);\n return 0;\n}<\/FONT>\n<\/PRE>\n
\nThis second thread is intentionally ill-behaved,\nso that we can see what happens when there’s a bad apple in the barrel.\nThe thread processes messages normally,\nuntil you hit the shift key.\nOnce that happens, it goes into another mode where it starts\nignoring the keyboard by stubbornly refusing to pump any keyboard\nmessages.\n<\/P>\n
\nNormally, this sort of recalcitrant behavior would affect only\nthe thread itself,\nbut since this thread is attached to the main thread,\nthe scope of the damage expands.\n<\/P>\n
\nint PASCAL\nWinMain(HINSTANCE hinst, HINSTANCE, LPSTR, int nShowCmd)\n{\n g_hinst = hinst;<\/p>\n
 if (SUCCEEDED(CoInitialize(NULL))) {\n  InitCommonControls();<\/p>\n
  RootWindow *prw = RootWindow::Create();\n  if (prw) {\n   ShowWindow(prw->GetHWND(), nShowCmd);<\/p>\n
  DWORD dwId;\n  CreateThread(0, 0, AttachedThreadProc,\n               IntToPtr(GetCurrentThreadId()), 0, &dwId);<\/FONT><\/p>\n
   MSG msg;\n   while (GetMessage(&msg, NULL, 0, 0)) {<\/p>\n
   if (ShouldLogMessage(msg.message)) {\n    prw->LogMessage(&msg);\n   }<\/FONT><\/p>\n
    TranslateMessage(&msg);\n    DispatchMessage(&msg);\n   }\n  }\n  CoUninitialize();\n }\n return 0;\n}\n<\/PRE>\n
\nWe modify our main program to create the secondary thread\n(which attaches itself to the main thread),\nand then to log messages in its message pump.\n<\/P>\n
\nOkay, now run this program and use the mouse to resize and\nreposition the two windows side by side with no overlap.\n(This will make it easier to observe what’s going on.)\nWave the mouse over both windows, and click on each of the\nwindows and do some typing,\nbut don’t hit the shift key yet.\nSo far, everything works as you expect:\nFocus switches back and forth, mouse and keyboard messages are\ndelivered.\n<\/P>\n
\nNow put focus on the bad window and tap the shift key.\nThis puts the bad window into\nfIgnore­Keyboard = TRUE<\/CODE> mode,\nwhere it stops pumping keyboard messages\n(but pumps everything else).\n<\/P>\n
\nWhat we just did is leave the WM_KEY­UP<\/CODE> message\nfor the shift key in the input queue,\nand steadfastly refused to process it.\nThe message just sits there forever.\nLet’s see what this does to the input retrieval algorithm.\n<\/P>\n
\nWave the mouse over the bad window.\nNotice that mouse events are still delivered to the bad window.\n(Keyboard events are not delivered because the bad thread\nis not pumping keyboard messages.)\nThis makes sense, because the filtered Peek­Message<\/CODE>\nfor\nWM_KEY­LAST + 1<\/CODE> through\n0xFFFFFFFF<\/CODE> includes the mouse message range\nbut excludes the keyboard message range,\nso the loop that looks for a candidate message completely\nignores the stuck keyboard message.\nAll it sees are mouse messages,\nand they are not stuck.\nThe code is taking advantage of the “peek into the future”\nfeature we mentioned yesterday.\n<\/P>\n
\nNext thing you notice is that if you wave the mouse over the\nmain window, it does not<\/I> receive mouse input.\nThat’s because the main window performs an unfiltered peek.\nThe stuck keyboard message satisfies the filter,\nand since that message belongs to another thread\nand is ahead of all the mouse messages,\nthe input manager will not return the mouse messages\nuntil the stuck keyboard message is cleared out.\n<\/P>\n
\nThis also provides an example of the paradox I alluded to yesterday:\nThe main thread is not receiving any input because it is performing\nan unfiltered message retrieval,\nand there is a stuck keyboard message in the input queue.\nOn the other hand, if the main thread had explicitly peeked\nonly for mouse messages,\nthen the stuck keyboard message would not have been taken into\nconsideration, and it would have gotten the mouse messages.\nThe paradox is that under these strange conditions,\na filtered message retrieval actually returns messages\nthat an unfiltered retrieval would not!\n<\/P>\n
\nNow here’s another trick:\nClick on the main window.\n(Yes, it’s not processing mouse input, but do it anyway.)\nNow both windows stop responding to input.\nWhat happened?\n<\/P>\n
\nBack before you clicked on anything,\nthe only stuck input message was that keyboard message.\nSure, there were mouse motions that took place,\nbut we saw that\n\nWM_MOUSE­MOVE<\/CODE> messages are generated on demand<\/A>\nrather than being posted into the queue when the mouse moves.\nTherefore, all that mouse-waving didn’t actually leave a stuck\nmouse message in the queue.\nOn the other hand, when you click,\nthat generates a mouse click event in the queue,\nand those are generated when the click happens,\nnot on demand.\nTherefore, when you click on the main window,\na click event goes into the input queue.\n<\/P>\n
\nNow think about what’s in the input queue:\nThere is a stuck keyboard message (for the bad window,\nwhich is stuck because the bad window refuses to pump keyboard messages),\nand there is a stuck mouse message (for the main window,\nwhich is stuck because the main window is waiting for the stuck\nkeyboard message to clear out).\nNew keyboard input will not be processed because of the stuck\nkeyboard message,\nand\nnew mouse input will not be processed because of the stuck\nmouse message.\n<\/P>\n
\nResult: Nobody gets any input.\n<\/P>\n
\nBonus investigation<\/B>:\nWhile you’re in this horrible state,\nopen Task Manager.\nObserve that the scratch program has pegged a CPU.\nWhy is it draining CPU when there is nothing to do?\n<\/P>\n
\nThere’s a little extra step in the overall algorithm that\ndescribes how input is processed:\n<\/P>\n