Spinning in _XReply
rami.ylimaki at vincit.fi
Fri Mar 4 00:42:45 PST 2011
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, xmail at karlt.net wrote:
>>> Rami Ylimäki writes:
>>>> On 02/22/2011 11:26 PM, xmail at 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.
>>> 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
>> 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
>> (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
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.
More information about the xorg-devel