Exactly as it says! One of the things said when the client was open-sourced was not to bother with multi-threading as it was being done, but the only evidence we've ever seen of that being done is the "Run as multiple threads" or some such in rendering options in the debug menus. However, SL still poorly utilises threads, if it even uses them at all. A ton of things cause SL to pause and stutter as it is forced to wait for something to happen, rather than simply creating a new process/thread to do the waiting while it continues working on more important things, like communicating with the server and rendering. I mean, even single-core/processor systems would benefit immensely from SL using threads to a greater degree as it prevents lock-ups caused by a slower part of the viewer causing other areas to wait. The result is a lot of inexplicable slow-downs or even momentary freezes. Examples of features which appear to causes pauses are:

• LOD re-calculation
• Occlusion culling
• Texture download/decompression (see VWR-1118)
• Rendering (I'm not convinced it's fully threaded yet as it wouldn't be stuck in a debug menu otherwise)
• Wearing red underpants on a Thursday

For this reason such things should have separate threads to handle these, so that others may continue undisturbed, reducing stutters and hangs, and improving performance on single-core, and especially multi-core systems.