[PATCH 3/4] user32/tests: Protect OpenClipboard() from interference.

[Francois Gouget]

On Thu, 3 Jun 2021, Francois Gouget wrote:
[...]
> I started with a loop of a mere 5x 10 ms but on my box in Wine that was 
> sometimes insufficient. These settings seem to work ok. I guess the loop 
> count and delays can be adjusted as long as other threads have about 300 
> ms to release the clipboard.

Actually there is a race condition that can lead to a deadlock so there 
is no point increasing the loop count.

Here is what happens:

1. test:
   - test_synthesized() calls OpenClipboard(temp hwnd) (l760)
   - Places some data in the clipboard for delayed rendering
   - CloseClipboard()

2. winex11:
   - Receives: request for selection "CLIPBOARD" target "TARGETS" prop "_QT_SELECTION"
   - X11DRV_SelectionRequest() calls export_selection()
   - Which calls OpenClipboard()
   - And then GetClipboardData() which sends a WM_RENDERFORMAT 
     message to the test window.

3. test:
   - Calls OpenClipboard()

So:
- The test is stuck in OpenClipboard() not processing the window 
  messages.
- winex11.drv will only release the clipboard once it has received a 
  WM_RENDERFORMAT reply.

This just does not happen on Windows (even with Radeon).


But I think there are more issues with this test. For instance:

# set up delayed rendering
806     r = EmptyClipboard();
812     SetClipboardData( tests[i].format, 0 );

819     r = CloseClipboard();
821     rendered = SendMessageA( hwnd, WM_USER, 0, 0 );
822     ok( !rendered, "%u: formats %08x have been rendered\n", i, rendered );

I think there is no garantee that winex11.drv will not send a 
WM_RENDERFORMAT message between lines 819 and 821 which would cause 
rendered to be true.


-- 
Francois Gouget <fgouget at codeweavers.com>