Dmitry Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@winehq.org wrote:
The problem is that once Get/PeekMessage handles an internal message it doesn't yield control to another thread and checks the message queue immediately, this misses a sent message from another thread and instead returns a previously posted one. I admit that this is a pure artificial thing that I stumbled upon, but it reveals a real bug in Wine with internal message handling.
This sounds like a simple race condition. Slowing down message processing may make it less likely to happen, but it doesn't fix anything.
Yes, it's a race, and it's caused by using internal messages for synchronization across the threads. Another way to fix this is by avoiding sending an internal message at all, and probably a test will show that Windows sends WM_ENABLE message from the source thread. Would you like to see such a test?
If you can avoid internal messages that's certainly good, but yes, I'd like to see more tests. In particular, for SetWindowPos you'd want to test using separate thread inputs, and how that work with changing the active window etc. Also SWP_ASYNCWINDOWPOS should be tested, from the docs it sounds very much like it needs an internal message.