Multithreaded or SelectNow?

[squidi]

I'm writing a mud, and I've got it to a point where people can connect and walk around and all sorts of fun stuff. I'm having a little conceptual trouble with how to communicate between two threads. It actually works, but I don't understand enough about what I'm doing to know if it will always work, or if I'm doing something which may hurt me later. Working between multiple threads is new to me, and I'm wondering if it might just be easier to go single threaded.

Basically, what I'm doing is as each client finishes receiving a completed line of text, that text is put into a command queue for that client. Then the other thread goes through all the clients, checks if they have a command, and if they do processes it. I'm already aware that the client list may change in the middle, so I'm thinking I'll have to use a separate list to hold clients with commands pending. But the queue for each client is synchronized, so I don't think  moving the commands between threads is a problem. And while the client does change during the course of the program, the parts the world model uses and the parts the server uses are pretty separate, such that I don't think either one will step on the other's toes.

Basically, I'm asking if this approach will work, of if there is a better approach to this problem out there? I'm new to both multiple threads and to network programming, so I'm really in over my head and pretty unsure about everything.

[Sakazaki]

I think it works if all threads read/write commands queues in a synchronized environment, as you suggest.
If I understood your approach basically you have a server thread that pool all active clients queue, process each command, and send a response throw client connection.
The only thing to take care in such solution is to synchronize queues (both clients and server), well... it not soo difficult, but debugging can be a nightmare if something do not work as expected (there are something wrong in client threads? in server thread? in queues synchronization?).
When I developed a mud server I choose to do it in a different way.
Each player is an object that "speak" with the clinet throw a connection (so one player one thread as in your solution, but only for I/O), a player receive a command string and pass the command to a command manager with a reference to itself. No queue in the "client side", only a command queue in the "server side" (server thread).
When the command manager receive this instruction process it and, if there are some feedback for player, use the payer reference to perform back comunications.
It's a quite similar approach, but I have only one command queue and I don't have a thread that "pool" each active connection; my server thread waits command from players and process it in a First In First Out way.
I don't know if this is the "best way to do this"^(TM), just an idea.
I think develop a mud environment is an interesting exercise, there are a lot of possibilities to do the same things 

Have a good job