Blocking sockets + a lot of threads, or non-blocking?

Started by
1 comment, last by Consty 13 years, 7 months ago
I'm making a text based MUD and the networking is a bit of a puzzle to me. I'm using winsocks and my first instinct was to make a thread pool so I can handle x amount of users per thread with a maximum of y threads. The idea was to find the most efficient values for those variables later. I thought if, later I determined I wanted 1 user per thread I could just set x to 1 and all would be well.

Now I'm thinking I'd be better off just using one thread per user and using blocking calls instead of non-blocking. I figure if I limit the threads to io only I could set the stack size to an extremely small value using the _beginthread() parameter so it won't be much of a waste of memory. If I'm just blocking and waiting for information I figure I can set the the stack size to the maximum size of the data buffer, plus a little extra just to be safe.

So my question is is it a bad idea to have possibly a thousand threads for io with the users? Should I just stick with the thread pool idea?
Advertisement
For a MUD, you should use a single thread, using select(), recv() and send().
enum Bool { True, False, FileNotFound };
Quote:Original post by BinaryStorm
I'm making a text based MUD and the networking is a bit of a puzzle to me. I'm using winsocks and my first instinct was to make a thread pool so I can handle x amount of users per thread with a maximum of y threads. The idea was to find the most efficient values for those variables later. I thought if, later I determined I wanted 1 user per thread I could just set x to 1 and all would be well.

Now I'm thinking I'd be better off just using one thread per user and using blocking calls instead of non-blocking. I figure if I limit the threads to io only I could set the stack size to an extremely small value using the _beginthread() parameter so it won't be much of a waste of memory. If I'm just blocking and waiting for information I figure I can set the the stack size to the maximum size of the data buffer, plus a little extra just to be safe.

So my question is is it a bad idea to have possibly a thousand threads for io with the users? Should I just stick with the thread pool idea?


This is less of an issue today because of the significant reduction in thread overhead. Depending on what you're doing with your game it could make a big difference. If you need a high data rate, it might be better to go with the thread pool method, because for example select() in Java NIO isn't able to perform as well as the standard socket mechanisms. You can read more information about it here: http://www.mailinator.com/tymaPaulMultithreaded.pdf

Personally I go with the select() method, just because it's easier to program. Having a separate thread for every connection is going to create concurrent nightmares for you when you have callbacks potentially accessing data structures from N number of threads. You'll need lots of synchronization to prevent issues like this. If you go with the one thread approach, it's a bit harder to setup initially, but easier to work with once the network code is in place.

This topic is closed to new replies.

Advertisement