[Xcb] magical callback funness

[Jamey Sharp]

On Thu, Mar 24, 2005 at 06:57:08PM -0800, Josh Triplett wrote:
> Jamey Sharp wrote:
> >>From the RECORD protocol spec: "[I]ntercepted protocol data are returned
> > to recording clients through multiple replies to the extension request
> > to begin protocol interception and reporting.  This utilization is
> > consistent with ListFontsWithInfo, for example, where a single request
> > has multiple replies."
> >
> > *sob* I *hate* ListFontsWithInfo...
> >
> > OK, apparently we need some general mechanism for XCB to handle multiple
> > replies with the same sequence number. Since I refuse to add callback
> > hooks to XCB again, and since I suppose clients will want each reply
> > with minimum delay (so no waiting for all replies and returning an
> > array), I guess XCB will need to store a queue of replies, and return
> > one per call to XCBWaitForReply.
> 
> Sounds like the correct way to handle it.  Presumably the
> XCBRequestNameReply function will return each reply in sequence,

Right: those just call XCBWaitForReply, so I meant that they should be
included implicitly.

> and

...?

> > We can add a tag to the XML-XCB bits, whose only effect in XCB is to set
> > a new flag in the XCBProtocolRequest structure. Josh, I'll be relying on
> > you to implement that: do you have any comments?
> 
> I have comments on the use of ListFontsWithInfo as an example for
> anything (except "how not to do things"), but I'll refrain from
> expressing them. :)

That's good. This is a family-friendly mailing list.

> I can easily implement that in XML-XCB; I just need to know the
> corresponding code to generate with the XSLT.  (I hope the structure of
> every reply is identical?  If not, then s/easily //.)

It occurs to me that I can actually implement this without any flag in
the protocol description. The implementation will be simpler if we
pretend like all requests could lead to an arbitrary number of replies.

My recent profiling efforts have shown that the linked list code in XCB,
used for things like the pending reply queue, accounts for the majority
of the CPU time spent in XCB. One of the alternatives I was considering
would actually amount to accepting replies for any request, independent
of whether any was expected. Extending that to accepting multiple
replies isn't a big leap.

I expect it'd be useful for XML-XCB to support an annotation declaring
that a request returns multiple replies. I don't see any harm in adding
one. But I guess it isn't necessary. So do as you like.

> > XCB can automatically tell that the last reply has arrived, when a
> > response of any sort having a higher sequence number arrives. Finding an
> > opportunity to remove the reply record is a little tricky, so I suppose
> > a first implementation will leak a few bytes for each of these evil
> > requests sent and we'll fix it once we've got the basics in place.
> 
> Do you really have to rely on getting something with a higher sequence
> number?  ListFontsWithInfo, at least, has a special sentinel reply at
> the end (zero-length font name).  Of course, the same approach of
> waiting for a higher sequence number would still work for
> ListFontsWithInfo.  I just need to know if ListFontsWithInfo and this
> RECORD request have the same reply semantics.

OK, the RECORD stream is terminated by a special EndOfData reply, still
following ListFontsWithInfo's model. (Ick.) But interpreting the reply
requires knowing what kind of request generated it, and deciding whether
you've reached the last one requires generating some kind of test
expression. We can do all that, but I don't think we want to.

> Regardless, if you really just wait until you see a reply with higher
> sequence number, then can't you just deal with freeing the reply data
> structure just as you would for the reply data structure created for one
> of Xlib's fake "I expect a reply for this void request" structures?  Or
> do those requests from Xlib not get reply data structures in XCB's
> expected-reply queue?

The same trick that works for Xlib will work here, certainly. But it
requires asking for the reply sometime after XCB can prove that no reply
can come. Requiring applications to ask for one more reply from, say,
ListFontsWithInfo after ensuring that some other request has been sent
and a response has been received... that seems excessive.

> (BTW, why does the function to set an unexpected reply callback still
> exist in XCB?  If Xlib no longer uses it, we should remove it entirely.)

Yes, we should. I expect I will any day now. If you want to do it
sooner, don't let me stop you. :-)

--Jamey