On Sat, Dec 01, 2001 at 11:52:47AM -0500, dman wrote: > Some programmers believe that threads should not be used at all, but > only processes that communicate via some sort of IPC. Those > programmers also believe that if your OS has processes that aren't > lightweight enough for that to be feasible, then it is a bug in your > OS; threads are not the right band-aid for the problem.
If I'm out for performance, I tend to go for neither if I can get away with it. Alan Cox once said: "A computer is a state machine. Threads are for people who can't program state machines." In my day job, I've seen just how stonkingly fast it's possible for code to go when it operates in a single process and uses non-blocking I/O. It eliminates all the context-switching rubbish and gives as much time as possible to the application, and the system stays responsive even under massive load. If you're processing lots of I/O streams, neither multiple processes nor multiple threads really scale far enough. There are downsides, of course - you have to have good libraries and a very disciplined programming style. It's certainly not the easiest model to use, and you still have to have good code in general. We're in the world of benchmarking here, though. -- Colin Watson [EMAIL PROTECTED]
