QThread and QTcpSocket [closed]

Question

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.

Closed 9 years ago.

I did serious mistake when I was doing some project and now I have to re-program it from bottom.. I'm writing multi-threaded server which will handle connections, requests, etc.. But, when I created new class with base object of QThread, I was starting thread with QThread->run(), not QThread->start(). Now I get bunch of errors. Here's situation. I have server, which creates new threads on each connection and starts reading data from each connected client.When I receive data, it emits signals which is connected to main GUI class and displays result OK. It also saves socket handle for replying messages. When I write data to socket from GUI class, it says this:

QObject: Cannot create children for a parent that is in a different thread. (Parent is QNativeSocketEngine(0x23a6c38), parent's thread is MyThread(0x1fb8670), current thread is QThread(0x9eb980)

What's wrong?

Answer 1

I know QT but am not intimately familiar with the QT socket implementation itself, but from the sound of your error message and the way you describe your design, your problem is not related to QT but to thread/socket architecture in general. Multi-threaded applications requiew careful thought intelligent design to be efficient and ensure that your session data etc is consistent and not fraught with concurrency problems, orphaned data structures etc.

It also saves socket handle for replying messages. When I write data to socket from GUI class, it says this...:

Without knowing all the details of your implementation, if you persisted the socket handle in thread 1 to respond to a call in thread 1, and then tried to write data to it from a call using thread 2, that original socket handle is invalid in the context of thread 2. This may explain your error message.

Persisting a socket handle for subsequent calls is not a good way to do things for any number of reasons (including the problem you are encountering.) Why are you doing that? If you need to persist client information across calls, use session structures to persist that data. If you want to keep the whole thread alive while the conversation back and forth continues, design your thread/socket interactions to behave that way and consider a thread pool, etc. But you should not have orphaned sockets just hanging around - each must exist in its own thread context and has no valid handle outside of its 'home' thread.

When a socket is finished with its conversation, the thread that was spawned and the socket created in that thread to continue the conversation are DONE - it should ALL be cleaned up.

If I understand your implementation correctly, my suggestions should fix your problem.

In your comment you mention:

"socket as a global variable" - you should NOT be using a global socket in such a way, if I understand correctly what you're doing.

Your server app should have a main thread with a persistent socket that listens for requests, when you get a request coming in there should be a signal emitted and the slot for that signal should spawn a thread that initializes a new socket for handing that request. Handle the request in the thread, then clean everything up, etc.

If you need to extract information from incoming requests and persist it somewhere, do it in the main thread and other threads should have no access to the structures you use to persist for that session in the main thread (unless you use synchronization mechanisms) Same thing if you want to get information out of the request processing when it's done - get it back out of the spawned thread into the main thread through a signal emitted when the thread terminates.

If you don't follow these rules, you need to use synchronization objects or you'll have all kinds of problems, including what you're experiencing, judging from the sound of your error message.

In short: "What happens in a thread, stays in a thread"