[Desktop_architects] [Announce] "Common Desktop Infrastructure" 0.1.0 is released

[Paul Davis]

On Thu, 2008-02-21 at 17:34 -0300, Tiago Vignatti wrote:

> Again, the same reason: the lack of developers. But try to ask someone 
> who already tried to use multiple threads under Xlib. It's a painful. 
> And this is one of the XCB beauties.

thats very much a matter of opinion. X made a very conscious design
decision very early on to impose no additional costs (i.e. mutexes) in
what was then percieved to be the common case: single threaded GUI code.
this is in marked contrast to (for example) the win32 drawing API(s)
which do the opposite: they require no additional application code to
handle mutexes for what was perceived by MS to be *their* common case:
multithreaded GUI code.

given that most developers working on X interact with it via a toolkit
which poses its own locking issues independently of X, solutions to "i
want to use multiples threads to call (GTK|Qt|FLTK|whatever) functions"
are generally going to be most significant within those same toolkits.
my primary app runs many, many threads that could theoretically interact
with the graphics subsystem, but uses an architecture so that only one
of them actually does so. this design works very well for many, perhaps
even most, applications.

don't get me wrong: i think XCB is an excellent idea and its a shame its
not crossed the threshold of being ready for use everywhere. but you
have been trying to make an argument about levels of the graphics stack
at which certain things need to happen, and i don't believe your
argument is sound or backed up by demonstrable evidence.

--p