On Thu, 24 Feb 2011 12:27:28 +1300, [email protected] wrote: > Rami Ylimäki writes: > >> On 02/22/2011 11:26 PM, [email protected] 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. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
