[xcb] Re: XCB

[Soeren Sandmann]

Jamey Sharp <jamey@cs.pdx.edu> writes:

> Can I encourage you to join the XCB mailing list? The relevant

I am sending this mail there.

> As I see it, the other answer to your question, Soeren, is that if the
> application has other stuff it could be doing, it doesn't need the reply
> yet, so it shouldn't make the possibly-blocking call. I haven't been
> able to think of any counter-examples, but I'd be happy to listen to any
> you can come up with.

Often an application wants to prioritize the handling of X events
above everything else in order to stay responsive. For example, an
application might want a calculation of pi to a million places to run
in the background, but as soon as an X event arrives, suspend the
calculation to handle the event.

This is difficult to do with threads as they are implemented on most
unixes, because threads are generally not fairly scheduled, so if the
application contains a busy thread when an X event is received, you
have no guarantee that the user interface thread(s) will be scheduled
anytime soon. Indeed, for cache and affinity reasons, the busy thread
will often be allowed to run for a full timeslice if it can. If a
burst of events arrives from the server and each one must wait for the
pi-calculating thread to finish its timeslice, the application will
feel unnecessarily sluggish.

A single-threaded, select()/poll()-based application can handle this
situation better, because it will be able to do its own scheduling and
schedule on smaller time slices. (And obviously such an application
can't block somewhere inside xcb).


S=F8ren