[Xcb] blocking

[Bart Massey]

In message <3EAC18F3.7060503@ludusdesign.com> you wrote:
> Bart Massey wrote:
> 
> > At that point, you know you might block, but by gosh you need to
> > block, since the app can't go on without the data.
> 
> No! This is the kind of assumptions that make me hate Xlib (and plenty 
> of other things, like gethostbyname)! The *X part* of the app might not 
> be able to go on without the data, but others might. Even at that, maybe 
> only a limited set of windows would be affected by the waiting on this 
> data, others should be able to carry on.

I wonder if the problem is that I haven't communicated well
here.

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.

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.

Comments?

	Bart