🔒 Locked

Threads or no threads?

Started by yahn Sep 19, 2006 at 6:21 PM 5 replies 1.2k views

Original Post

Sep 19, 2006 at 6:21 PM

I'm not sure if this should be in game programming or in network programming. It's asking more for advice on game programming then it is with network programming, so I posted here. I'm creating a socket dll for a game I'm making and I need the socket not to block while I'm waiting for it to receive. I already know how to use select(), but I'm thinking I should probably use a thread for this situation. I already have the server coded to use select. I thought it would be better for the server to use select since it will be dealing with a lot of sockets. I figure it would be better to use a thread for the client since they will only have one socket. What are your thoughts on weather I should use a separate thread or just use select()? And can you give a reason why you feel its better to use a thread or select()? If you think I should use a thread, do you know of any good place to learn how to use threads? Thank you for your time.

DrEvil

155

DrEvil

Sep 19, 2006 at 6:37 PM

select(), a thread per client is wasteful. I believe the FAQ has more details.

See question 10 in the networking faq.

http://www.gamedev.net/community/forums/showfaq.asp?forum_id=15

yahn

Author

yahn

Sep 19, 2006 at 7:10 PM

Yes, but that seems to be referring to the server. I said that I have the server using select(), but I think that the client should maybe use a thread. I don't think question ten in the FAQ answered my question.

Kylotan

Mod

3,487

Kylotan

Sep 20, 2006 at 8:48 AM

It doesn't really make all that much difference when you're only dealing with 1 socket. Do whatever is easiest for you.

markr

159

markr

Sep 20, 2006 at 9:43 AM

In your client code, if you've got a game logic loop (which presumably you do), you may as well read the socket inside that loop, reading all pending messages each time, actioning them if necessary (of course depending on the network strategy this may involve queuing them for future use).

There seems to me to be no advantage in reading from the socket asynchronously (i.e. in another thread) when it only really affects your game logic loop anyway. It will just create synchronisation issues without affecting the performance of the game (much).

Mark

sbougerolle

Sep 20, 2006 at 11:31 AM

In a client-server game the game logic loop is probably on the server, whereas the client would be running an event loop.

There are all sorts of problems you can run into trying to manage both GUI events and socket data.

Spinning the socket loop off to another thread is one approach. I went that way with my client and it works pretty well. The only hassle with it is needing to use mutexes.

Another approach is to set up an idle callback and read the socket in between GUI events. If you do that then you need to make sure your idle handler doesn't block the GUI.

A third approach is to try to turn your socket data into events. This doesn't seem to work well for many people, though. I tried it at first and dumped it in favour of the threaded approach, just ran into too many weird problems.

Which one is the right answer for you depends on your particular needs and problems, and what toolkits and OS you're developing with.

JasonBlochowiak

Sep 22, 2006 at 5:03 PM

I have my socket data handling code on a separate thread. Right now, I'm only using the queued data synchronously, but this way I have the flexibility to handle any traffic I want async, which is something I expect I'll be using in the future.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.