> Richard L. Hamilton wrote: > > A truly multithreaded > > X server would help though, so that xlsfonts -lll > wouldn't be > > a DoS attack, but I expect that's a lot to ask.) > > We'd be more likely to EOL the ancient core fonts, > except for the > two required by the protocol. There are very few > things the X > server can do in multiple threads that take long > enough to care > about and don't end up all waiting on the same lock > for access to > the hardware. If you really worry about having to > protect the > X server from yourself, you can also change your font > path to > redirect all legacy font accesses off to a font > server, effectively > putting that code into an out-of-process separate > thread.
Like I said, "I expect that's a lot to ask." My desire for such a thing is maybe a bit more theoretical than anything (wanting all the concurrency I can get), although xlsfonts -lll with old fashioned core fonts rather than a font server or client side rendering is a pretty dramatic _example_ of how to make a single-threaded X server get very obviously bogged down. I didn't literally mean that someone might use it as a DoS, so much as the effect. But whether there are other examples that really demonstrate a performance hit from inability to handle requests truly in parallel as much as possible, I don't know. I would imagine that they'd exist, but the effect would be nowhere near as obvious, esp. lacking something better to compare against. Anyway, I'm well aware I was off into pie-in-the-sky with that one. (And I half suspected that you'd point out something along the lines of the cost/benefit probably not being there on that. I could swear I'd heard long ago of an experimental multi-threaded X server, but I don't recall whatever became of it. Clearly, it didn't catch on, since Xorg isn't using it.) -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
