user32: After handling an internal message give a chance to real message to arrive.

[Alexandre Julliard]

Dmitry Timoshkov <dmitry at baikal.ru> writes:

> Alexandre Julliard <julliard at 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.

-- 
Alexandre Julliard
julliard at winehq.org