https://bugs.winehq.org/show_bug.cgi?id=53435
--- Comment #3 from Esme Povirk madewokherd@gmail.com --- I'm having trouble reproducing this bug to see what the messages in question actually are, but this doesn't make much sense to me. We have a MsgWaitForMultipleObjects call waiting 0.1 seconds for qs_all_input. But we haven't sent our window any messages. So this is just.. waiting 100 ms and expecting nothing to come in.
But, there are plenty of messages we ignore for logging purposes. So either this is one of our ignored messages (in which case it should be expected that they would affect the queue status too), or the queue status changes for no reason (much less likely).
This could be here for the todo_wine_if. In the thread_2 case we have the internal SetParent things messing things up so that we end up with a sent message at the end, on Wine. Without the wait, Wine would succeed or fail depending on the timing of the background thread's SendMessage. But, that failure case is already accounted for by the message sequence tests, particularly before this point. We also have plenty of tests for GetQueueStatus functionality.
I think maybe we should delete this one GetQueueStatus check. We can't know the correct value until after we clear out the queue with a PeekMessage (or really a PeekMessage loop, as we want to specifically ignore any messages that MsgCheckProc ignores).