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

Dmitry Timoshkov dmitry at baikal.ru
Mon Apr 27 06:53:03 CDT 2015


Alexandre Julliard <julliard at winehq.org> wrote:

> >> >> Why do you need to leave the function instead of checking for further
> >> >> messages? What is the issue you are seeing?
> >> >
> >> > If you mean the only quoted piece of code (MSG_POSTED case) then only
> >> > reason of the change is to make it consistent with the sent message case.
> >> 
> >> I don't really see any reason to make it consistent, but I'd like to
> >> know why you need the other one too.
> >
> > The other one is needed to make the test pass for the sent message case.
> > If you have a suggestion how fix it differently please let me know.
> 
> I may have one, once I understand what you are trying to fix. What is
> the actual problem that prompted you to write the tests and the fix?

The problem is described in the first test for sending inter-thread
messages: https://www.winehq.org/pipermail/wine-patches/2015-April/138750.html
My original guess was that the problem is caused by internal message
handling in Wine, and the tests I created confirmed that there is a problem
in that area. The patch we are discussing fixes the problem discovered
by these tests.

Another guess was that it's a race between EndDialog and DestroyWindow
leading to a crash. According to my tests under Windows EndDialog called
from another thread never returns.

At the moment I'm inclined to another theory about the source of the problem:
it's the implementation of SetWindowPos called for another thread window,
and the tests+patches I sent today confirm that. Moreover it looks like
the real fix for the problem.

There are other discovered problems caused by DestroyWindow from window's
thread+SendMessage from another thread, but let's leave them aside for
the time being.

-- 
Dmitry.



More information about the wine-devel mailing list