In message <20030427104627.098f7c2f.raster@...> you wrote:
> On Sat, 26 Apr 2003 14:05:57 -0700 Bart Massey <bart@...> babbled:
> > OK, after dicussing with you and after long talks with Keith
> > Packard and Jamey today, I think what we need is a tiny
> > extension to XCB:
> > XCBGenericResponse *XCBWaitResponse(XCBConnection *c)
> > XCBGenericResponse *XCBPollResponse(XCBConnection *c)
> > where an XCBGenericResponse is either an XCBGenericRep
> > (consisting of reply data tagged by its sequence number), an
> > XCBGenericError, or an XCBGenericEvent. XCBPollResponse
> > will return 0 if nothing is available, XCBWaitResponse will
> > block (duh). Once a cookie's reply has been returned by
> > XCBPollResponse, the cookie becomes invalid for further use
> > (duh).
> i don't see how the XCBGenericResponse hooks up to any of
> the Cookies returned by xcb calls. there's nothing in
> common there. from an api standpoint i generally dont like
> digging into data structs - i like them opaque, but the
> mechanism of using cookie->seqnum sounded better and
> comparing to the connection seqnum. personally i would
> think providing accessor functions to provide for a nice
> api would be better there. ie "has the seqnum of this
> cookie been recieved yet" that would do just fine.
The answer to your first question is that if the
GenericResponse is a GenericRep, one of its fields is a
sequence number to match against cookies'.
We can do the latter thing. As I suggested in a previous
message, we can provide
int XCBForcingWouldBlock(XCBGenericCookie c)
which I think answers the question you posed.
Does this answer your question?
> also i have to ask why all the cookie data structs are
> different per request, but they end up all being the same
> internally with the same single int value? what was the
> reason for this? this makes doing the above kind of work
> harder - either i have to assume this and cast them all to
> int's or special case every single cookie reply type - and
> theres no "parent" type i can rely on to be common. ?
The whole idea is to enforce static type checking, making it
difficult to pass e.g. a pixmap cookie to a routine that
wants a property cookie. Casting the cookie to a
GenericCookie and taking its sequence number field is
harmless: the cookies are all guaranteed to have this.
XCB definitely encourages a different programming model
(actually several different models) than e uses. I don't
think it's hard to make XCB do pretty much what e needs,