CORE-15147
- Rename CLIENTTHREADINFO::tickLastMsgChecked into timeLastRead as
documented in https://reactos.org/wiki/Techwiki:Win32k/CLIENTTHREADINFO .
This is the last time the message queue was read.
- This is the structure member one must compare against the current tick
count timestamp in order to heuristically determine whether a message
queue thread is hung!! Fix MsqIsHung() in accordance, add extra debug
logging in order to help us determining which of our code present
regular GUI hangs, and add as well an extra "TimeOut" parameter so as
not to hardcode a fixed value within that function but instead
allowing its caller to specify possible different values.
- THREADINFO::timeLast is on the contrary the last message time stamp,
and will definitively differ from CLIENTTHREADINFO::timeLastRead .
It should only be used for information purposes!
- Accordingly, in NtUserGetThreadState()::THREADSTATE_UPTIMELASTREAD
and in InitThreadCallback(), only (re-)initialize the timeLastRead
member of the CLIENTTHREADINFO structure of the THREADINFO of interest.
- In co_IntPeekMessage(), update more often the timeLastRead timestamp
whenever the current message queue has been read (but NOT timeLast!!
That one will be updated ONLY WHEN a message is found!).
- In co_IntSendMessageTimeoutSingle() first check whether the window to
which we send the message is being destroyed, before checking for
queue hangs etc. Collapse the logic checks for queue hang and increase
the hang timeout check to 4 times MSQ_HUNG (== 4 * 5 seconds) and
display a debug trace.
SendNotifyMessageW: It doesn't support messages with pointers so there is no need to call MsgiUMToKMMessage
SendMessageTimeoutW, SendMessageTimeoutA: These two do support marshaling pointers so they need to use MsgiUMToKMMessage.
This is actually a bug that happens only in the rare case where we send a WM_COPYDATA with a timeout.
