Spinning in _XReply

[Rami Ylimäki]

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.
>>>
>>> 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