Spinning in _XReply

Karl Tomlinson xmail at karlt.net
Thu Mar 3 15:20:12 PST 2011

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

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.

More information about the xorg-devel mailing list