[Xcb] magical callback funness

[Jamey Sharp]

On Fri, Mar 25, 2005 at 12:44:24AM -0800, Josh Triplett wrote:
> Jamey Sharp wrote:
> > On Thu, Mar 24, 2005 at 06:57:08PM -0800, Josh Triplett wrote:
> >>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.

Yup. A null return is, of course, a normal error return and would occur
anyway if the application didn't stop asking for the reply -- assuming
that the application had sent a request that had been acknowledged
somehow. Otherwise the thread will permanently hang at that point. :-(

> > 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.
> 
> If you don't think it'll hurt performance, that sounds like an optimal
> design.

The initial implementation will take a small performance hit compared to
what's there now, due to an extra malloc call or two. Nothing we can't
fix later as needed.

I'm more concerned about whether it will make XCB harder to use. I like
the fact that the current implementation has the ability to detect
errors at run-time both for unexpected replies and for expected replies
that never come. This change will make those run-time checks harder.

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

Yeah, it could do that, but that involves a linear-time walk through the
queue: not so good, but the best I'd come up with so far. (Also I built
an abstraction layer around the linked lists in XCB a long time ago, and
that layer makes this particular walk a little awkward. It's also become
a performance limit. It'll go away eventually.) I think a better data
structure will be necessary, but we'll have to see how the initial
implementation falls out to figure out how it should work.

> >>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!" :)

Yeah, my comment was a joke too. Dead-pan delivery is less effective in
e-mail. I suppose matters were made worse as people who don't know you
might be inclined to take me seriously.

;-)

--Jamey