You should thing about the design of the thread first as I have the impression that you don't know how should the thread behave. In the first place -- are you sure you need the thread at all?
You should thing about the design of the thread first as I have the impression that you don't know how should the thread behave. In the first place -- are you sure you need the thread at all?
The idea:
The idea of the program is that the server will handle different clients. Everytime a client is connected to the server, this one will create a thread that will contain all the information about the client.
This thread will also be used to receive and send messages to the client.
When the client disconnects, then the thread dies.
I didn't mean "what the thread should do" but rather "how the thread should do it" -- design, not purpose.
You have to start by thinking -- "if I was the thread, how would I achieve the task, what would I need and why". Then you should think of each of the procedures the same way, just in more detail until you have the whole concept in your head of even on paper (this way you won't forget about anything). Then you can start thinking about the implementation itself (meaning, what modules of the environment I use will fit best to what I want to do).
Because as for now I don't see a reason to use threads at all... I would just hold the connections in some data structures and connect appropriate signals to custom slots and implement everything in an event driven way. But, of course, I don't know the nature of requests that are to be handled. Depending on what they are to be and how are they to be handled, it could be better to use threads.
Bookmarks