X display locking

[Aaron Plattner]

On 03/12/2013 11:52 AM, Torsten Jager wrote:
>> Applications should never call those functions - they are Xlib's
>> internal locking mechanism for the request buffers.
>
>> Applications should only call XInitThreads() to set up the locks
>> before any Xlib calls are made.

I think Allen must have been thinking of the Xlib internal LockDisplay 
and UnlockDisplay functions.  However, those functions aren't necessary 
unless you need multiple requests from one thread to be atomic w.r.t. 
other threads using the same display connection.  For your use case, it 
sounds like you don't need them.

> Thank you for answering.
>
> You are confusing me. My manpage says
>
>    "It is only necessary to call this function if multiple threads
>     might use Xlib concurrently."
>
> In other words, it _is_ necessary im my case.
>
>> You shouldn't get lockups unless you take the lock in one thread and
>> don't release it.  You did call XInitThreads() as the very first thing,
>> right?
>
> Yes.
>
>>> Hovever, on my mate's box the same code traps both libGL and
>>> libvdepau into an infinite sched_yield () polling loop.
>
>> Sounds like a bug.
>
> Well, my mate just reported the issue gone with new nvidia drivers
> 304.84 and 313.26. Funny though, I did not have that problems with
> 310.32 here.
>
> Anyway, I #define'd out all calls except for the XInitThreads ()
> right before the initial XOpenDisplay (). Verified this by looking
> at the symbol import tables of the resulting binaries.
> Then, everything was fine - as long as I kept moving the mouse
> pointer over the applications output window. When I stopped,
> something like this happened:
>
> Thread 17 (Thread 0xb639eb70 (LWP 12037)):
> #0  0xffffe430 in __kernel_vsyscall ()
> #1  0xb73cb75e in poll () from /lib/libc.so.6
> #2  0xb7273470 in _xcb_conn_wait (c=0x8114bb8, cond=0xb639e190, vector=0x0,
>      count=0x0) at xcb_conn.c:313
> #3  0xb7274db7 in xcb_wait_for_reply (c=0x8114bb8, request=4291, e=0xb639e22c)
>      at xcb_in.c:378
> #4  0xb7565d58 in _XReply (dpy=0x8125538, rep=0xb639e290, extra=0, discard=0)
>      at xcb_io.c:533
> #5  0xb754af76 in XGetWindowProperty (dpy=0x8125538, w=31458047, property=287,
>      offset=0, length=2147483647, delete=0, req_type=287, actual_type=0xb639e30c,
>      actual_format=0xb639e310, nitems=0xb639e318, bytesafter=0xb639e314,
>      prop=0xb639e31c) at GetProp.c:61
> #6  0x080c112d in xitk_is_window_iconified (display=0x8125538, window=31458047)
>      at window.c:68
> #7  0x08083df5 in slider_loop (dummy=0x0) at panel.c:444
> #8  0xb747db25 in start_thread () from /lib/libpthread.so.0
> #9  0xb73d646e in clone () from /lib/libc.so.6
>
> Thread 15 (Thread 0xb2a1db70 (LWP 12039)):
> #0  0xffffe430 in __kernel_vsyscall ()
> #1  0xb7482125 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
> #2  0xb7552e74 in _XConditionWait (cv=0x8125fc8, mutex=0x81274c8) at locking.c:353
> #3  0xb7565d15 in _XReply (dpy=0x8125538, rep=0xb2a1d0bc, extra=0, discard=0)
>      at xcb_io.c:527
> #4  0xb52ff220 in ?? () from /usr/lib/libGL.so.1
> #5  0xb6bd1ff4 in ?? ()
>     from /usr/local/lib/xine/plugins/2.2/xineplug_vo_out_opengl2.so
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> OK I am a xine developer.
>
> Using the unchanged Kaffeine frontend (which works with the locking
> around libGL) is even worse off - heavy input activity is needed to break
> the freeze.
>
> The stack corruption message probably is just a result of gdb losing track
> inside proprietory libGL.
>
> But even with no locking from my side, we got stuck here.
>
> I think of 2 possible causes:
>
>    * the "applications should not use" policy had been added later than my
>      libX11 version, or
>
>    * KDE 4.4 does interfere somehow. I guess it has to, at least to
>      intercept Alt-Tab and similar stuff even if the app itself does not
>      even link against kde or Qt libs.
>
> Any ideas?

What version of XCB are you using?  There were a significant number of 
thread-related problems introduced when libX11 first switched to using 
XCB as a backend.  I'd suggest using a libX11 built without XCB, but 
doing that has gotten a lot harder on recent distributions.

This deadlock kind of sounds like this one:
http://cgit.freedesktop.org/xcb/libxcb/commit/?id=23911a707b8845bff52cd7853fc5d59fb0823cef

-- 
Aaron