Andrew Eikum aeikum@codeweavers.com writes:
Backtraces of the two threads below. My understanding is the DestroyWindow is waiting for the second thread to handle the WM_WINE_DESTROYWINDOW, while the second thread is waiting for the first thread to call SetEvent.
Windows doesn't send WM_WINE_DESTROYWINDOW, so DestroyWindow exits and the test calls SetEvent.
There might be a race condition in the test, if the first thread sends WM_WINE_DESTROYWINDOW before the PostQuitMessage's WM_QUIT causes the second thread's event loop to exit. However, it deadlocks every time for me.
I don't think we want to simply ignore the failure and keep child windows alive when their parent is gone. Probably the sequence could be changed so that WM_WINE_DESTROYWINDOW is sent first, and WM_DESTROY is sent in the context of the target thread.