[SOLVED] Need suggestion about sockets and threads in Qt.
-
Hi, I'm trying to write simple chat program, which will contain server where it will be located (e.g 192.168.1.2) and client(s)(192.168.3-255) which will be connected to server. When I entered IRC channel of Qt, people advised me to NOT use threads for this, but I really don't understand why. When new client connects, it should live in it's own thread to not conflict others (server delay in this case, when one processing something, other can't because they live in the same thread). They advised me to use event loops. Is there a big difference if client count would be 3k+ ?
Regards.
-
Hi,
if client count would be 3k or more you'll have problems also using a single thread for each connection.
As a general rule the QtNetwork module allows you to connect to more peer without threads; obviously if client count would be huge you should consider different solution.
-
Won't be QThread's the solution? Each client will live in it's own QThread, I think this will be faster than event loop for each client. What is difference between these? Do QThreads take more memory than new object + event loops ?
Regards.
-
Threads take resources, and they'll make programming harder. But in the end, they still need to use a single shared resource: the network. So what's the point in using threads at all? Why do you expect that there will be lag between clients if you don't use threads? Only if you need to do heavy processing for each connected client it could make sense to do that in separate threads. But that seems unlikely for a simple chat application...
Note that QtNetwork allows async programming already, without using threads. I concur with the advice you got on IRC to stay away from threads for the time being. Also note that you'll only be using a single event loop. Just make sure you don't block it by creating tight loops or by using synchronous API (avoid all waitFor* or exec functions!).
Edit: also note that starting 3k threads or so will make your program much slower, not faster. You make the CPU change context all the time to do a slice of work for a different thread. That is costly. You'd have to use threadpool or something like that anyway. You really don't need such a complication...
-
Hi,
writing a server that manages 3k connections it's a very hard task. many commercial servers doesn't allows such count.
If this is a requirement for you you should think to use some specific technique (for example a process pool with internal multithreading).
-
Thank you all, I learned a lot from these posts :-)
can administrators close this thread please?
Regards.
-
Nope, threads are not closed. At least, not for a reason that the one starting it is done with it. Moderators only close threads that really get out of hand, or that are duplicates of other threads.
If you want to mark a thread as "come to a resolution", simply edit your first post and prepend [SOLVED] to the title.