Spinning in _XReply

[Michal Suchanek]

On 16 March 2011 02:40, Karl Tomlinson <xmail at karlt.net> wrote:
> 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.
>

As pointed out earlier, opening another connection just happens to
return the right error codes, just like calling Xlib functions from
the error handler it is not guaranteed to do anything sensible.

Thanks

Michal