[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg
Subject:    Re: X display locking
From:       "Torsten Jager" <t.jager () gmx ! de>
Date:       2013-03-19 17:56:57
Message-ID: 20130319175657.68520 () gmx ! net
[Download RAW message or body]

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: freedesktop-xorg@progressive-comp.com
[prev in list] [next in list] [prev in thread] [next in thread]