[xcb] Re: XCB

[Soeren Sandmann]

Bart Massey <bart@cs.pdx.edu> writes:

> The problem with callbacks in single-threaded-land is that
> there's no very convenient way to get the non-local
> flow-of-control change in UNIX/C when the data is available.
> One can arrange to receive SIGIO on the socket and call the
> callback from the signal handler, but this is fraught with
> peril, and is in the end just simulating a second thread.

Well, I agree that calling arbitrary callbacks from a signal handler
is bad. What I had in mind was something like

        XCBCookieSetNotify (..., void (* callback) (XCBCookie *));
        XCBSetEventCallback (void (* callback) (GenericEvent *));

and then when the XCB socket selects as readable, you would call a
function

        XCBDoYourThing ();

(maybe with a better name :-)), that reads everything there is to read
from the socket, calls the installed callbacks, and returns.

What I am really thinking about is what it would take to layer gtk+ on
top of xcb, and gtk+ really wants to do its own scheduling, although
it can work with threads.

> If you want this style, I'd recommend having a second thread
> to execute the callbacks.

I explain in my other mail why I don't think threads are always such a
good idea.

> That said, one of the drawbacks of the XCB model (that I've
> just realized while typing this) is that there's currently
> no convenient way to block until any one of a number of
> cookies is ready.=20=20

As Jamey said, X guarantees that replies arrive in the same order the
requests were sent, so it should be possible for the application to
figure out which one of several cookies it should block on.


S=F8ren