[bisected] mesa xdemo/glthreads get some black windows

Submitted by fangxun

Assigned to Jamey Sharp @jamey

Link to original bug (#30450)

Description

Created attachment 39041 xorg log

System Environment:

Platform: pineview Libdrm: (master)2.4.21-21-g7ec9a1effa4f551897f91f3b017723a8adf011d9 Mesa: (master)9476efe77ff196993937c3aa2e5bca725ceb0b41 Xserver: (master)xorg-server-1.9.0-71-gc768cdda92696b636c10bb2df64167d5274b4b99 Xf86_video_intel: (master)2.12.0-87-g08c2caca48323d6d5701dcef3486f850619d7905 Kernel: (master)9fe6206f400646a2322096b56c59891d530e8d51

Bug detailed description:

Startx and run mesa xdemo glthreads, we get some black windows, not rotating cub. Sometimes get still cubes. Bisect shows it's caused by LibX11. 933aee1d is the first bad commit. commit 933aee1d Author: Jamey Sharp jamey@minilop.net Date: Fri Apr 16 20:18:28 2010 -0700

Fix Xlib/XCB for multi-threaded applications (with caveats).

Rather than trying to group all response processing in one monolithic
process_responses function, let _XEventsQueued, _XReadEvents, and
_XReply each do their own thing with a minimum of code that can all be
reasoned about independently.

Tested with `ico -threads 20`, which seems to be able to make many
icosahedrons dance at once quite nicely now.

Caveats:

- Anything that was not thread-safe in Xlib before XCB probably still
  isn't. XListFontsWithInfo, for instance.

- If one thread is waiting for events and another thread tries to read a
  reply, both will hang until an event arrives. Previously, if this
  happened it might work sometimes, but otherwise would trigger either
  an assertion failure or a permanent hang.

- Versions of libxcb up to and including 1.6 have a bug that can cause
  xcb_wait_for_event or xcb_wait_for_reply to hang if they run
  concurrently with xcb_writev or other writers. So you'll want that fix
  as well.

Reproduce steps:

1. xinit &
2. ./glthreads -n 6

Attachment 39041, "xorg log":
Xorg.0.log