CPU hog?
Hi.
I''m attempting to make a non-blocking server to work on windows and *nix. I currently have a while loop constantly checking for new connections and receiving data. and of course its eating up cpu like popcorn.
Right now its all in the one process using a single thread.
I was wondering if anyone could give me some suggestions so that I don''t exactly have the cpu 99% of the time dedicated to the server?
Would having a thread for each client be a good thing? a dedicated thread for accept()''ing new connections (blocking of course, doesn''t hog cpu right?)?
Thanks in advance
Use select(). It can do everything you need done, portably.
You shouldn''t use threads unless you really know what you''re doing. I guess you''re trying to write a game; now in games, players (i.e. clients) interact a lot - that''s the point of a multiplayer game after all. This means that all threads would constantly try to access the same set of data. It''s a locking nightmare, which can easily be avoided by using only a single thread. The single-thread solution is going to be more efficient anyway (unless you''re running this on a multi-processor system).
cu,
Prefect
Return to the Shadows
You shouldn''t use threads unless you really know what you''re doing. I guess you''re trying to write a game; now in games, players (i.e. clients) interact a lot - that''s the point of a multiplayer game after all. This means that all threads would constantly try to access the same set of data. It''s a locking nightmare, which can easily be avoided by using only a single thread. The single-thread solution is going to be more efficient anyway (unless you''re running this on a multi-processor system).
cu,
Prefect
Return to the Shadows
Widelands - laid back, free software strategy
June 12, 2002 09:41 AM
If you have a game loop with the main time is spent rendering, doing AI etc. you could just leave it non-blocking and test your network connections once per frame and you''ll be fine. Using select is probably a better option though, especially if you have many connections or something...
In my programming, I have a thread for each client, and a thread for server data input...
If you were MEANT to understand it, we wouldn't have called it 'code'
In most cases, using a thread per client isn''t a very good idea. You will use more time context switching than you will processing game logic (depending on the number of connections). Threading isn''t giving you anything unless you are running on a multiprocessor system, even then using more threads than you have processors is likely just wasting cycles. Of course, if you are using APIs that block, you need to use it in it''s own thread so that other processing can continue. If you use non-blocking APIs, then you are better off running in as few threads as possible (#threads <= CPUs).
Fingh is right again. Although I would like to add that having a thread for network writing is good for ''smoothing'' out the data. It''s easier on routers that way.
One thread for reading all your sockets using select(). One for writing all your sockets for smoothing out data flow.
One thread for reading all your sockets using select(). One for writing all your sockets for smoothing out data flow.
Stephen ManchesterSenior Technical LeadVirtual Media Vision, Inc.stephen@virtualmediavision.com(310) 930-7349
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement