[Xcb] XListFontsWithInfo works, finally!

[Jamey Sharp]

On Wed, Mar 30, 2005 at 11:19:16AM -0800, Jamey Sharp wrote:
> Oh. I think I know what the X Test Suite regression was now. The tests
> that hung must have been expecting error responses; XCB noticed that the
> "current reply" was the one it wanted, but saw that no reply was
> available ('cause it wasn't a reply, it was an error) and kept waiting
> for a reply to come. Darn it, my code's going to get ugly. *sigh*

I've committed a fix for this that I believe should work for all
Xlib/XCB uses. Now XCBWaitForReply first searches the event queue for a
relevant error (returning immediately if one is found), then stores its
XCBGenericError** argument into its reader queue entry. In the following
loop that blocks until a reply is available, an additional termination
condition is now that if an error has magically appeared in that
pointer, the loop ends. (There's a fairly complex array of termination
conditions on that loop now. I'm wondering if they can be simplified
any.)

The error can magically appear there because the function that processes
incoming responses, when it sees an error, checks to see if there's a
reader blocking on the sequence number of that error, and stores the
error through the provided pointer instead of into the event queue.

This isn't a complete solution, but because Xlib/XCB always uses
XCBWaitForReply in one of two particular ways, I'm pretty sure it's
correct for that case. (And the X Test Suite doesn't hang any more, and
neither do my window manager or gdm, which turned out to be affected.)
The alternate case that's not yet supported is if the caller provides a
null XCBGenericError**, in which case XCB will currently fall back to
enqueueing the error in the event queue... which is the correct
behavior, except that the reader still needs to be notified somehow that
it should stop blocking. I think I know how to fix that.

--Jamey