   Should new multiplayer instances spawn another thread or process on server?
  So I've written to what amounts to a lobby so far.  Players can start games or join games from this lobby.  Now on the server side, when a player starts a game it currently runs on the same thread as the rest of the server.  I am wondering if when a player starts a new game, should it spawn a new thread or process or should I keep it on the same thread.Thanks in advance.   
  using a different thread would make some sense considering that the goal of one thread would be to process lobby functions while another thread(s) would process running instances.   ;  I've thought about that in the past, but right now it's beyond the scope of the question.  I am more concerned if each match on the server should be it's own thread/process.  Like if a user starts a game, it would launch another program on the server and that 'server instance' would run only that game.;  If your server has multiple cores then you'd wanted to spawn a new thread. You might even try to create a thread pool and run a number of instances on each thread.Definitely want to use threads over processes here though. However, this is a problem if your game matches memory leak or crash or do something odd since it can take down the lobby server.Also to make sure your threads take nearly 0% CPU run the update step in a fixed-time loop where you update then immediately go to sleep for the rest of the time.For each thread you might just have simple// lock a mutex and check the queue of pending games that need to be queued into a thread and grab one to process// loop through and update all the games in the thread then sleep the remaining time and discard all finished games that are running in the threadA little bit more too it, but that could be the basic idea.So your lobby would simply get players together then insert the game into a queue to be picked up by a worker thread.[Edited by - Sirisian on May 10, 2010 5:43:01 PM];  The game shouldn't care how it's hosted.I would initially host them in a little thread pool with 4 or 8 threads, throw each game on one (pick the least busy, or round-robin, whatever).Later you can move these to different processes or, more likely, different boxes. The "game" itself shouldn't care, the interface that the host uses to control the game shouldn't need to change.   ;  Thanks for your replies.SirisianWhy threads over processes?Started doing some research on thread safety and found this http://www.codeproject.com/KB/threads/xylock.aspx  (will it be enough to start the ball rolling?)CadetUmferNothing to add, good input.Just to be clear, single threaded server to handle same game but different matches of game is a big no-no.  Right?[Edited by - AlwaysLearning on May 10, 2010 3:16:58 PM];Quote:Original post by AlwaysLearningStarted doing some research on thread safety and found this http://www.codeproject.com/KB/threads/xylock.aspx  (will it be enough to start the ball rolling?)Are you familiar with boost? You might enjoy the boost thread library. It'll help to keep your code readable. Ideally you don't have much communicating between the threads so you'll be doing only a few locks.Quote:Original post by AlwaysLearningWhy threads over processes?I can't think of a clear advantage that individual processes would give you over a thread pool.Quote:Original post by AlwaysLearningJust to be clear, single threaded server to handle same game but different matches of game is a big no-no.  Right?Not necessarily. You could run your whole game in a single thread. The only problem is that if you're running on a multicore processor you'll end up neglecting the other cores. This is mostly a problem of scaling. If you were to run a single threaded application on a quad core server for instance it'll sit on one core and the other cores will normally just sit around doing barely anything. The alternative of using a thread pool would allow you to keep all the cores busy.// also I'm going to go back and clean up the previous post I typed up quickly. >_>   ;  In the past I tried to learn boost.  It wasn't a good experience.  I'll give this boost thread library a look though.I was only considering a different process so I wouldn't have to deal with thread safety - which I'm completely new to.  I'm also new to raknet and networking and the graphics api that I am using.  Just don't want to spread my focus too thinly.Is this it?http://www.boost.org/doc/libs/1_43_0/doc/html/thread.html   ;  Your server should have the same number of threads as it has cores. This should be fixed, it shouldn't change with how many instances are running.If there's one instance and 8 cores, it should be computed over 8 threads. If theres 64 instances and one core, they should all be computed on the same thread.   ;Quote:Original post by AlwaysLearningI was only considering a different process so I wouldn't have to deal with thread safety - which I'm completely new to.The concepts are the same either way you go. It's just that processes enforce safety whereas threads force you to have to think about it. If you want you can use inter-process communication between different threads which will give you pretty much the same safety guarantees, with the only exception being that you have to watch out for globals and static variables. If you don't use any of those, you're probably ok.   