Threads?

If I''m right too much threads will only make the process slower. In theory you should have a thread per processor, per application. But sometimes doing it anyway might help though.

I wouldn''t do it though, but I never used threads anyway

Your best off seperating the network code out into another thread just so that it can run concurrently with your main loop. That way your never waiting on data to be recv''d/sent or something in your main loop to finish.

Well, if your game has only got 4 players, then there''s no point in using threads at all.

There are two reasons for using threads:
1. You''re writing a GUI application and you need to perform a task that takes a lot of CPU power or might block due to something else (heavy I/O for example, or using blocking sockets).

2. You''re writing a heavy load server that is likely to run on a multiprocessor system.

In case 1 you need to put the CPU intensive job into a different thread so that the GUI part of the program remains responsive.

In the second case you just utilize additional processing power.

More than one thread per processor doesn''t make sense unless you''re doing something which might put the thread into a sleeping state (e.g. I/O operations). However, in that case it''s better to use non-blocking sockets or asynchronous I/O instead of just throwing more threads at the problem.

Also you shouldn''t use one thread per player. If you want to use threads, use a pool of worker-threads which can be freely assigned to any player as needed.

More threads usually only hurt for two reasons:
1. Additional resource overhead at the OS level plus additional task switches.
2. If you''ve got worker-threads, you might come into a losing situation where a certain event (such as new data) might release all threads from a waiting call. Then all threads need to run for a small timeslice just to realize that the arriving data has already been processed by another thread.

cu,
Prefect