Using non-blocking IO is just the old select loop in C. You just wait in a loop that goes and checks if you can read from anyone yet, if you can then do a little processing, else go back and check again.

This has key advantages over blocking and threading. The biggest is that starting a new thread is expensive. A second one is that you get more flexibility over your control logic. A third is that by having less going on in parallel, you have fewer internal races to deal with.

This has key disadvantages as well. The biggest is that if something occupies your thread for a bit, everything comes to a halt. Another is that there are now race conditions between your noting that there is external input and your taking advantage of it. A third is that you wind up doing a classic "busy wait", occupying significant system resources in just finding out that you have nothing to do.

In reality, of course, most computers only do one thing at a time, but simulate doing many things by switching between them rapidly. (SMP computers are, of course, exceptions. But even they typically seem to be doing more things at once than they have CPUs.) All that blocking versus non-blocking really means is whether you are handling the switching logic in your code, or whether that switching is being handled at a lower level (eg in the OS).

Which is better? My belief is that, "It depends." But I would say that if you have pervasive multi-threading, then blocking IO is safer since it handles more race conditions automatically. But when given a choice, I prefer single threading to having multi-threading.

Cheers,
Ben

Keeping pools of objects around so that you can reuse existing ones is an old optimization to avoid expensive creations. The very fact that this has been noted as a bottleneck and the optimization applied for thread creation is evidence that thread creation is expensive. Whether it works for you depends on your usage pattern, but if your process hangs around for a while, both asking for and returning objects, then the odds are very good that your usage pattern fits.

The fact that this can beat a select solution means little. As I mentioned, select has its own performance drawbacks. (Such as busy waits.) Similarly note that the performance of heavily threaded code is strongly OS dependent. It is no accident that you used NT and Solaris as your examples, but not Linux or HP-UX.

For more, a lot more, I find [link|http://www.kegel.com/c10k.html|The C10K Problem] a good read. I am fairly sure that you have seen it before, but there probably have been updates since you last read it, and there are a lot of links that are just plain good. Among other relatively recent additions are links (which I have admittedly not read) on how non-blocking I/O can be a performance win for Java.

Cheers,
Ben