On 03/04/2011 01:20 AM, Karl Tomlinson wrote:
On Thu, 24 Feb 2011 12:27:28 +1300, xm...@karlt.net wrote:
Rami Ylimäki writes:
On 02/22/2011 11:26 PM, xm...@karlt.net wrote:
Although wrong, our code has been working well enough for us to get
useful information. If someone is able to point out a reason why
this now works less successfully than previously, then that would
bump up the priority at our end.
By superficially looking at the Xlib code, the behavior in older
Xlib version (1.3.3) is different depending on whether Xlib is
configured --with-xcb or --without-xcb. When Xcb is disabled,
error handler is called with display unlocked and _XReply seems to
be prepared to handle requests from error handler. With Xcb, which
is the default now with Xlib 1.4, the display remains locked
during error handling and nested requests aren't allowed.
It looks like the display locks are no-ops unless XInitThreads is
called or when built with --enable-checked-locks.
http://lists.x.org/archives/xorg-devel/2011-February/019533.html
does seem to indicate another potential issue (breaking from the
loop only when "req == current"). I guess that hasn't bitten us
because we don't return to the first _XReply.
That seems to have been the situation until
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=933aee1d5c53b0cc7d608011a29188b594c8d70b
I see that we now spin even without XInitThreads.
That is version 1.3.4 --with-xcb.
I'm expecting to fix this as part of
https://bugzilla.mozilla.org/show_bug.cgi?id=576933
(Fall out from GDK not expecting input devices to disappear.)
I'm planning to open another connection to get the extension
codes. Although there's no promise we'll get the right codes in
the future, it shouldn't hang.
Opening another connection could be perhaps avoided by using Xcb
directly for the XListExtensions and XQueryExtension requests. The Xlib
Display pointer can be converted to an Xcb connection with
XGetXCBConnection and that could in turn be used to execute the same
requests with Xcb. You could ask the codes from the correct connection
without worrying about internal Xlib problems.
If XInitThreads is used, the call to XSynchronize in the error handler
is also problematic and I don't think it's possible to determine whether
the Xlib connection was synchronous or not from the error handler with
enabled locks.
-- Rami
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
