>threads. It's been well argued that by simply giving every activity >its own thread, you let the operating system do on its own what you >were trying to do manually, and the computer can do it better than you This has its limits. Doesn't work for compute-intensive tasks where you're trying to scale up a computation linearly with the number of processors.
For citserver, which is a nonuniform grab-bag of various protocol implementations, threading is correct. There's just too much going on in citserver as a whole to successfully cram it all into one thread. But there are times when you want to limit the overall level of concurrency in your server, in order to play nice with various external resources. That's when the thread pool model becomes important. You need to be able to spawn lightweight tasks, as objects which describe what needs to be done, and push them onto a queue where they will await processing by the thread pool.
