gcs584:

Sorry, I didn't mean to be confusing. What I meant was that you have to think about how your OS implements multi-threading. That is, they don't exactly run *at the same time* (assuming uni-processor). What it does is (very generally) switch back and forth really fast. Each time it switches however, it has to load the relevant details of each thread into the CPU. This may be registers and what not.

However! I took a quick look at the link you provided. Multi-threading may be ok for things that aren't time-critical (I mean, things that have to constantly update). For instance, code that retrieves data from the network layer, server-browser code, etc. This is (I think) because you can just simply let these threads block and let the real-time threads (eg. the game thread) take over.

Thing is, you don't really want the server code to run in a thread. By "server code" I mean any server-related code that runs in a tight loop. This thread will compete with your "client thread" (which also runs in a tight loop) for the CPU. This will most likely cause the OS to quickly switch back 'n' forth between the threads thereby causing a lot of overhead. Worse yet, the OS may decide to give a chunk of time to each thread causing the other thread to stall.

Anyway, I hope that makes more sense. Looks like you got your answer from the anonymous poster though.

-j