[PATCH] user32: Reimplement destroy_thread_windows() on top of WIN_DestroyWindow().

[Paul Gofman]

On 10/13/21 20:08, Marvin wrote:
> Hi,
>
> While running your changed tests, I think I found new failures.
> Being a bot and all I'm not very good at pattern recognition, so I might be
> wrong, but could you please double-check?
>
> Full results can be found at:
> https://testbot.winehq.org/JobDetails.pl?Key=99988
>
> Your paranoid android.
>
>
> === debiant2 (32 bit WoW report) ===
>
> user32:
> msg.c:9208: Test failed: WaitForSingleObject failed 102
> msg.c:9214: Test failed: destroy child on thread exit: 0: the msg 0x0082 was expected, but got msg 0x000f instead
> msg.c:9214: Test failed: destroy child on thread exit: 1: the msg 0x000f was expected, but got msg 0x0014 instead
> msg.c:9214: Test failed: destroy child on thread exit: 2: the msg sequence is not complete: expected 0014 - actual 0000

It looks like these test failures (which are in fact random) are not a 
coincidence and are triggered by the patch, although the core issue is 
probably the preexisting race in WIN_DestroyWindow(): 
WM_WINE_DESTROYWINDOW sent to other thread child currently should be 
processed before WIN_DestroyWindow() reaches server with destroy_window 
for the parent. Otherwise, during destroy_window() in the server the 
server part of child windows is destroyed and the messages to them get 
cleaned up from the queue. So the grandchild thread in test waiting for 
the message for its grandchild window never gets it. I am looking into 
how that can be solved.