Spinning in _XReply

[Rami Ylimäki]

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.

Even the older _XReply contains a comment indicating that doing requests 
from an error handler wasn't considered good behavior even though it 
happened to work previously:

     /* Pull out the serial number now, so that (currently illegal) requests
      * generated by an error handler don't confuse us.
      */

> 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.
>
> I guess we could use a separate connection to query the extension
> codes.  Is it reasonable to assume that all connections to the
> same display would use the same codes?

X server seems to preserve the extension codes until the server is 
regenerated and therefore all connections should use the same codes.

-- Rami