Spinning in _XReply

[Karl Tomlinson]

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.