Re: XListFontsWithInfo works, finally!

On Wed, Mar 30, 2005 at 09:59:55AM -0800, Barton C Massey wrote:
> Awesome!  When you're awake again, I'll want to see some
> details.  Good work.

Ah. Details. Right. :-)

> In message <20050330114121.GC29028-sH+B+fTmh7PR7s880joybQ@xxxxxxxxxxxxxxxx> 
> you wrote:
> > I couldn't sleep,

Possibly due to a rather severe neckache, but probably only because I
couldn't stop thinking about how to make this work.

> > so in a sleepless haze I figured out the details of
> > how XCB should handle multiple replies, as in ListFontsWithInfo and
> > RECORD requests. I even got memory management just right, I think.

I finally got it through my head that there's a "current reply" which is
the only one that can recieve more replies. So I added a current_reply
queue, which stores the (possibly multiple) replies that haven't been
fetched yet by the app for the current incoming sequence number. When
the server sends some kind of response indicating that a later request
has been processed (which could be a reply to that later request), the
current_reply queue is checked to see whether there's anything in it. If
there is, then that queue is moved into a map from sequence numbers to
queues and a new current_reply queue is allocated; otherwise, well, it's
an empty queue so we can reuse it. Unlike past implementations, I don't
try to correlate errors to requests at this stage now.

When the application asks for the reply to a particular sequence number,
XCB checks whether the sequence number is for the "current" reply,
dequeueing from current_reply if so, and otherwise fetching the
appropriate queue from the replies map. In the second case, if the queue
is empty after dequeueing something (which is trivially true if it was
empty before) then we can free both the queue and the map entry. If this
process results in a null return value (the queue was empty, perhaps, or
there was no entry in the map for that sequence number) and the caller
provided an error pointer, then XCB searches the event queue to see if
an error arrived for that sequence number.

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*

Anyway, this mechanism has the interesting effect that for today's
applications, the replies map will almost never get used. It also means
that allocated memory is freed as soon as possible, and there are no
inherently linear-time operations needed to handle replies at any stage.
(The map is currently implemented as a linked list, so all its
operations are currently linear time, but obviously it's pretty easy to
do better.)

> > Of course, as promised, much of XCB's run-time error checking is
> > gone now; we'll have to figure out how to put it back later.

The _xcb_in_expect_reply function is presently a no-op, and I was
"forced" to remove the unexpected reply handler callback because there's
no longer any way to tell whether a reply is expected. :-)

> > Together with a single-character bugfix to Xlib, XListFontsWithInfo
> > "just works" now.

I changed a '<' to a '<=', because the equality case could (and
frequently did) cause XCB to block, but in this chunk of Xlib I needed
it to never block. (It's the chunk that pretends like replies are
expected for all requests that Xlib sends.)

This also avoids the problem I was concerned about where
XListFontsWithInfo would drop half its replies. At least, I think it
does. I'm haven't managed to test conclusively yet.

By the way, because Xlib/XCB still depends on the memory layout of the
XCBConnection structure, anyone testing it will need to recompile it or
your apps will all crash on startup. This is as good an argument as any
for devising a more abstract API for Xlib to use, as far as I'm
concerned. Recompiling Xlib every time I change the XCBConnection is a
pain.

> > I've gone through the five stages of grief over this stupid request,
> > I swear.

Google says that those would be denial, anger, bargaining, depression,
and acceptance.

--Jamey