[Xcb] a question about request and reply

Barton C Massey bart at cs.pdx.edu
Tue Dec 13 16:13:17 PST 2005

In message <20051213194642.GX4199 at id.minilop.net> you wrote:
> On Tue, Dec 13, 2005 at 07:16:45PM +0100, Vincent Torri wrote:
> > On Tue, 13 Dec 2005, Barton C Massey wrote:
> > > Yes, the reply is currently queued until you force the
> > > cookie, so you'll leak memory.  Nothing worse. :-)
> If it's still there after about four billion more requests have gone by
> then you'll get bad data probably. :-)

That's a bug.  We should fix it---it shouldn't be hard.

> > > It seems to me pretty straightforward to add
> > > XCBDiscardCookie(GenericCookie) to the interface.
> >=20
> > there is a GenericCookie ? I've only see VoidCookie and all the others
> > corresponding to the requests. I think that such a structure should be
> > added.
> There isn't a GenericCookie, and I don't want to add one. Functions like
> XCBWaitForReply just take the 'unsigned int' from inside the cookie
> structure. I don't want to encourage casting structures any more than I
> have to.

Yeah, that's fine.

> > > Non-blocking, and if called before the reply is delivered
> > > simply sets a bit saying the reply should be discarded when
> > > it arrives.  Is this something we need/want?
> >
> > maybe for the reply code ?
> xcb_reply is probably the strongest example of why "DiscardCookie"
> functionality is *not* needed: if xcb_reply needs this functionality, it
> can set a flag in its own queue and, when the reply arrives, free the
> data without invoking the callback.
> In other words, this can be built on top of XCB's current interface, so
> I'd need to see a very compelling use case to consider adding it to XCB.

xcb_reply starts a separate thread; I agree that it's not
the interesting case.

The cases I can think of offhand that *might* be interesting
enough to warrant it are (a) you issue a request, then later
discover the reply will be moot, or (b) you issue a request
purely for the side effect, without ever intending to look
at the reply.  In either of these cases, you might want to
be able to just ignore the reply in a non-blocking way.

However, I can't think of a concrete example for either (a)
or (b).  Further, the issue of error handling raises its
ugly head afresh if you do this.



More information about the Xcb mailing list