Spinning in _XReply

[Rami Ylimäki]

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