Dispatching and scheduling--basic questions

[Alan Coopersmith]

Adam Jackson wrote:
> That said, we have seen some cases where threading would be a real win.
> Moving input to a thread for latency reasons looks like it's definitely
> worthwhile.  Some hardware operations like DDC are slow out of
> proportion to the rest, and might be worth executing asynchronously.
> Fortunately the dispatch code is equipped to handle this; we have the
> ability add things to idle work queues, timers, the ability to put
> clients to sleep for a while and complete their requests once the async
> task finishes, etc.

The old xfs split used those to effectively put some font operations into
a separate thread as well, though one with it's own address space.  That
was mainly a win for large Asian-locale fonts with thousands of glyphs
that took a long time to load and process.  Most clients today move that
font "thread" into their own process via Xft/render.

The other place Sun found to add threads was in our Xinerama implementation
of OpenGL - it would run a thread per GPU to process GL commands that
crossed multiple screens.   Unfortunately, I think that code is locked
away in our licensed-from-a-third-party version of OpenGL.   (I guess Xdmx
could be used to essentially simulate thread-per-GPU X, with the penalty
of all that overhead communicating between the master & slave servers.)

-- 
	-Alan Coopersmith-           alan.coopersmith at sun.com
	 Sun Microsystems, Inc. - X Window System Engineering