[Xcb] Re: blocking

[Bart Massey]

Sorry it's taken me so long to reply---things got
ludicrously busy for a moment.

In message <3EAF2ABC.4080605@ludusdesign.com> you wrote:
[...]
> > The idea in XCB is that the cookie is a "lazy" representation of the
> > data, like in a lazy programming language.  As long as you treat the
> > cookie in an opaque way, it's a first class object that causes no
> > blocking: your app can go off and do other work, you can make other X
> > calls, etc with no penalty.
> 
> This sounds good, yes.
> 
> > When you actually need to inspect the data---for your app to process
> > it, to send it back to the X server, etc---then you have to force the
> > cookie: this may block if the data "underlying" the cookie has not
> > yet been received from the server.  But this latency is somewhat
> > unavoidable: you can't possibly operate on data you don't have yet
> > :-).
>  >
> > I think we might add a call to XCB to poll whether forcing a 
> > particular cookie would block:
> > 	int XCBForcingWouldBlock(XCBGenericCookie c)
> > returns true or false in the obvious fashion.  Is this what you were
> > looking for?  I'm not sure that it helps with any particular
> > programming style---what does one do differently if it returns
> > true?---but it's easy to add and might have some use that I'm not
> > currently seeing.
> 
> I'm not sure it would do. You see, I think you should be able to know 
> precisely when a cookie has arrived and act on it when I get it. I'm not 
> in too much of a hurry, I can wait until it arrive to do whatever 
> depends on it, but I really don't want to block everything (including 
> things that might have nothing to do with it).
>
> This proposed call would make it pollable. If you have multiple cookies 
> in flight, this would require you to poll on each of them, is that it?

No: you only have to poll on the first one you received,
since X processes requests in order.

> Is there a callback driven interface to cookies?

One could use select() plus either XCBForcingWouldBlock() or
XCBPollResponse() to implement a callback interface on top
of XCB.  This is what I am suggesting happen.  I don't think
the callback mechanism itself needs or wants to go inside
XCB: it's not any easier to implement in there, would
increase the size of XCB, and isn't the suggested XCB style.

> Or is "forcing a cookie" a way for the application to say
> "the hell with it, I can't do *anything* without this
> cookie",

Yes.

> the usual way being to receive a callback or something?

No, the usual way is for the application to wait until it
has to say "to hell with it" and then force the cookie :-).
This sometimes leads to slightly less latency hiding than a
callback mechanism (especially if the application is not
careful to request data as soon as it knows it might need
it).  Usually, though, latency is only slightly worse than
the minimum possible, and with the upside of implementation
usually being much simpler.

Hope this helps!

	Bart Massey
	bart@cs.pdx.edu