Under Windows, a process is MUCH more expensive than a thread, it terms of both memory and CPU cycles. For the CPU to do a context switch from one thread to another is almost nothing compared to do the same context switch from one process to another. It's really an enormous difference when you get right down to it. That's the simple explanation without getting into page faults and the process space complexities that are at the core of this issue.
You really have to look at your problem and see how it breaks down to figure out what type of solution will work best. It may be possible that you only need one or two threads to handle that many concurrent tasks. That is, if the state machine for your system lends itself to that type of design. Just look at most modern web servers, if they were to spawn a thread per connection, most servers would die under the load of only a few hundred users, and I really doubt you'd get more than a hundred concurrent users if you went with a process per connection. The scalable solution is to use a small pool of threads to handle all the work. It all comes down to the design of the system, in the case of high performance, high reliability applications, design is everything.
Of course, everything I've said is null and void when applied to the UNIX environment, where processes are the preferred method of multi-tasking.

John
[email protected]