Unless you have multiple processors, or parts of your task can be put to sleep on block, you always lose power be separating a task into more threads. Your adding context switching costs and you still have the same amount of CPU power no matter how much you chop it up.
A standard way to increase performance in server situations is finer-grained optimization. Sun is famous for their boasts that Solaris has many many more synchronization locks than any other OS, allowing it to make much more precise scheduling decisions, and hence more likely to extract better performance in any given situation.
In reality, if your tasks cannot be broken up like this, you've probably not designed your server properly, and are never going to get good performance. However, even if that weren't the case, then to say "you always lose power" is at least misleading: e.g. if you are buying an Intel processor these days it's actually hard not to end up with a multi-core CPU. Sun, IBM, and Intel have all claimed that multicore CPU's are the way forwards, and at various times hinted all their future CPU's will be multicore. On top of that, it's currently standard for internet hosted servers to be dual or quad CPU (can be annoying when you want a low-CPU-power machine and e.g. just want lots of RAM - you end up having to pay more for CPU power you certainly don't need).
And on single core CPUs at the hardware level, all modern desktop CPU's are optimized for multi-threaded execution. There is silicon dedicated to this task on Intel and AMD processors, and has been for years.
I agree with others that I cant see a value in using multiple selectors.
On the contrary, I would say that if you care about performance then - in theory - it is foolish to use only one selector. This doesn't guarantee that in practice it is best, but from my personal experience multiple selectors deliver performance no worse than single selectors.
To be *absolutely* clear: for most stuff people want to do, one selector is fine. It's not the best approach, but its certainly good enough - you won't notice differences in performance, because other things in your code will be having bigger effects.
However, multiple selectors give you the following advantages:
- fine-grained control of server resources: allow you to favour incoming connections, existing connections, or completed connections (ACCEPT, READ, WRITE). If you're doing serious server development, you will almost certainly have situations where you know exactly what balance you want between those three, and mutliple selectors allows you to optimize for it.
- cleaner, more modular, code: e.g. your connection-building code is completely independent from your response-sending code, save that one has - ultimately - got to call a Selector register method to transfer the work to the other. You have limited the dependency to a single simple method call, making debugging, optimization, and ongoing development much easier