On 03/04/2011 10:32 AM, Rami Ylimäki wrote:
On 03/04/2011 01:20 AM, Karl Tomlinson wrote:
On Thu, 24 Feb 2011 12:27:28 +1300, [email protected] wrote:
Rami Ylimäki writes:
On 02/22/2011 11:26 PM, [email protected] 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
Also, a word of warning about asking extension list with Xcb. The latest
unreleased version of Xcb has a regression related to iteration over
extensions:
https://bugs.freedesktop.org/show_bug.cgi?id=34037. However, this should
be easily fixable, when someone finds time to do it, and you shouldn't
be affected by yet unreleased versions.
-- Rami
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
