X display locking

[Torsten Jager]

> 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.

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?

Torsten