Spinning in _XReply

[Karl Tomlinson]

Jamey Sharp writes:

> So I don't see anything we can do except require that callers meet the
> documented requirements for XSetErrorHandler. I did try to find a kludge
> to let existing apps survive this bug, but anything I could think of
> probably breaks multi-threaded clients.

Thanks for the follow-up.  I'm happy to fix our client to avoid
protocol requests on the display passed to XSetErrorHandler.

(Life must be difficult for multi-threaded clients using
XSetErrorHandler, but I imagine there are ways to make things work.)

> On Wed, Feb 23, 2011 at 10:26:21AM +1300, xmail at karlt.net wrote:
>> The information we want is already on display->ext_procs->codes
>> but "This structure is private to the library."  I'm not aware of
>> a public API to get this information from Xlib.
>
> Eh, that hasn't stopped anyone else who's using Xlib. :-/
>
> One thing you could do if you don't want to use private APIs is to call
> XListExtensions (and XQueryExtension, if you need event and error
> numbers) when you open the Display.

We usually try to do as little as possible on start-up.
This may not take much time, but little things add up.

> Otherwise, screw it, I'd just include Xlibint.h and dig out
> ext_procs->codes.

I feel more comfortable opening another connection.  The
consequences are less severe if codes ever change than if
structures change.

> On Fri, Mar 04, 2011 at 12:20:12PM +1300, Karl Tomlinson wrote:
>> > 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 not sure what this means. Do you mean you spin due to re-entering
> _XReply from _XError, or because of something involving the "req ==
> current" condition?

Re-entering _XReply from _XError, which we'll avoid.

> With the patch I just pushed, I think calling XSynchronize should once
> again be safe from an error handler.

Yes, that's my understanding too.

That's helpful, thank you.