Hello! > 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.
1.7 > This deadlock kind of sounds like this one: > http://cgit.freedesktop.org/xcb/libxcb/commit/?id=23911a707b8845bff52cd7853fc5d59fb0823cef Thanks. Contained in 1.9 I use now. But this was not enough. I also needed a patch from recent libX11. Seems those lockups have gone with those. > 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. Well, with OpenGL omitting X(Un)LockDisplay () led to significantly worse performance - kernel mode processor load up to 20%, which used to be <4% before. Lots of additional context switches and cache flushes. Looks like my previous quick fix of bracketing the whole frame conversion/output sequence is not that bad. Torsten _______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com