[Xcb] magical callback funness

[Josh Triplett]

Jamey Sharp wrote:
> AIEEEEE!

Seconded.

>>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, 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. :)

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 //.)

> 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.

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?

(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.)

- Josh Triplett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20050324/8e3768b0/signature.pgp