[Changing subject and moving to xwin-discuss as we rathole on this tangent.]
Richard L. Hamilton wrote: > I could swear I'd heard long ago of an experimental multi-threaded > X server, but I don't recall whatever became of it. I've got the research paper somewhere, but I believe the results are pretty much as described - it got slower because it added the overhead of everything waiting on the lock to the frame buffer. Now, that was almost 2 decades ago, and technology has progressed, and there are some places threading may make sense. For instance the Sun SPARC OpenGL would use a thread per graphics device in Xinerama mode, since those wouldn't be contending for the same hardware lock. Similar would probably make sense for other drawing operations on multihead systems. We actually have a few threads running in the OpenSolaris version of Xorg today, performing very limited tasks that don't interact directly with the main server thread. But retrofitting a 25-year old multi-million line code base to be completely thread-safe, much less thread-hot, is not a small task. And since we already have GPU's that run 128 or 256 operations in parallel without adding any threads to the core server, it's not clear what the effects would be. That's not to say X is ignoring the multi-core revolution completely. The XCB API that's slowly replacing Xlib as the base of the client side of the graphics stack was designed from the ground up for much better concurrency support, as well as much more flexible latency handling. For instance, I recently tackled porting xwininfo from libX11 to libxcb, and after artificially introducing latency via ssh -X from California to Beijing and back, got a little over a 10x performance improvement, simply because the xcb API let me choose when to wait for the answers to my queries, instead of Xlib blocking for a synchronous reply to each one, so I could send off a whole batch at once and wait for the answers to come in as I was ready for them: Xlib: 0.03u 0.02s 8:19.12 0.0% xcb: 0.00u 0.00s 0:45.26 0.0% (from http://lists.freedesktop.org/archives/xcb/2010-June/006111.html ) Of course, xwininfo is very much a corner case of an X application, since all it does is request a ton of info from the X server, process it, print some and request some more - while most X applications spend the bulk of their time not waiting for the X server to respond but for something else (the user to make input, a remote web server to provide http data, your local javascript interpreter to run the downloaded code, etc.). -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
