[Xcb] magical callback funness

[Josh Triplett]

Jamey Sharp wrote:
> 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
>
> ...?

Sorry, that was apparently incomplete.  I was going to say "and return a
NULL or similar when the last response is read.".  However, since both
ListFontsWithInfo and this RECORD request have a terminating reply, then
that won't be necessary, as the application can already determine when
it has reached the end of the protocol stream.

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

That was a joke, hence the :). :)  I had no non-family-friendly comments
in mind, just a big "DON'T DO THAT!" :)

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

If you don't think it'll hurt performance, that sounds like an optimal
design.

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

It's necessary for other applications of the protocol descriptions, so
I'll be putting it in at some point.  However, that point may be further
in the future if XCB doesn't need it.

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

As mentioned above, eventually XML-XCB does indeed need to describe the
exact test for when the last reply has been seen, for the benefit of
other applications of the protocol descriptions.  However, the solution
of always expecting multiple replies sounds ideal for XCB's purposes.

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

Ah.  I assumed that since the pending reply queue was ordered by
sequence number, that when XCB actually received a reply with a higher
sequence number, it would know that there were no more replies to the
request with lower sequence number, and therefore that it could either
1) free the memory associated with the pending reply structure, if the
replies have already been retrieved, or 2) if the replies have not yet
been retrieved, mark the reply structure to indicate no more replies are
expected, so that once the replies are retrieved, the structure can be
freed.

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

:)

- 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/20050325/dee13148/signature.pgp