PDA

View Full Version : QTcpSocket no signal when using in a thread



mentalmushroom
8th April 2011, 17:17
Hello. I am trying to use non-blocking sockets inside a thread, but I don't receive connected signal. Below is my code and method socketConnected is never get called.



class Downloader: public QThread
{
Q_OBJECT

public:
Downloader(QList<Segment> &segments):segments(segments)
{
bool con;
con = connect(&sock, SIGNAL(connected()), this, SLOT(socketConnected()));
sock.connectToHost("myhost",119);
}

void run()
{
exec();
}


~Downloader()
{
}

protected slots:

void socketConnected()
{
// do something

}



protected:
QList<Segment> &segments;
QTcpSocket sock;

};

wysota
8th April 2011, 17:28
Please search the forum (or the web) for "qt you're doing it wrong". If that's not enough search the forum for thread+socket.

mentalmushroom
8th April 2011, 17:54
I found this page for the mentioned request: http://labs.qt.nokia.com/2010/06/17/youre-doing-it-wrong/
They say about threads affinity and the need to subclass QThread. Is there something wrong with the thread affinity?

I also tried to do it this way, but still doesn't work:


class Downloader: public QThread
{
Q_OBJECT

public:
Downloader(QList<Segment> &segments):segments(segments)
{
}

void run()
{
QTcpSocket sock;
bool con = connect(&sock, SIGNAL(connected()), this, SLOT(socketConnected()));
sock.connectToHost("myhost",119);

exec();
}


~Downloader()
{
}

protected slots:

void socketConnected()
{
// never gets called
}


protected:
QList<Segment> &segments;
};


I know subclassing QThread is not necessary, but this approach is more convenient for me: no need to create two objects (Worker and QThread) , no need to establish extra connections (just call wait).

I don't understand what is wrong with the code.

wysota
8th April 2011, 18:04
You have to handle signals for your socket in the same thread as the affinity of the socket. Furthermore an event loop needs to be running in this thread.

mentalmushroom
9th April 2011, 12:33
Ok, thank you for the explanation. I've just tried the following code. It doesn't work if I call QThread::wait for the thread where worker is running, and that seems to be strange, because that thread must call exec and process all events.




// Worker declaration (worker.h)
class Worker : public QObject
{
Q_OBJECT

public:
Worker();
~Worker();

signals:
void finished();

public slots:

void start();
void socketConnected();
void socketError();
void socketDisconnected();

private:
QTcpSocket sock;
};

Q_DECLARE_METATYPE(Worker*)



// usage (main.cpp)
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);

qRegisterMetaType<Worker*>();

QThread *t = new QThread;
Worker *w = new Worker;
w->moveToThread(t);
bool con;
con = QObject::connect(t, SIGNAL(started()), w, SLOT(start()));
con = QObject::connect(w, SIGNAL(finished()), t, SLOT(quit()));

t->start();
t->wait(); // !!! this causes a problem

return a.exec();
}


As far as I see event processing in the worker's thread doesn't affect anything, but the 'outer' thread does (here it is the main thread). I tried to change the code and place it inside of the other thread:



// this is how outer thread works
void MyThread::run()
{
qRegisterMetaType<Worker*>();

QThread *t = new QThread;
Worker *w = new Worker;
w->moveToThread(t);
bool con;
con = QObject::connect(t, SIGNAL(started()), w, SLOT(start()));
con = QObject::connect(w, SIGNAL(finished()), t, SLOT(quit()));
con = QObject::connect(t, SIGNAL(finished()), this, SLOT(quit()));
t->start();

exec();
}

// and this is how MyThread is used
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);

MyThread *t = new MyThread;
t->start();
t->wait();

return a.exec();
}


The last code works, I think because of QThread::exec called inside MyThread::run. But I thought that event processing must be performed by that thread where I moved my Worker object (called t in my case). Could you clarify this, please?

wysota
10th April 2011, 00:28
Consider what is the thread affinity of the socket in your first snippet in the previous post.

mentalmushroom
10th April 2011, 07:55
I call w->moveToThread(t), this should push worker object (along with all its members like sock) to the thread t. As far as I know, by default t performs event processing in its run method simply calling exec. So I have QTcpSocket that belongs to the thread t, event processing in the thread t, and signals processed by the slots of Worker object that also belongs to the thread t. What is wrong with socket affinity?


int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);

qRegisterMetaType<Worker*>();

QThread *t = new QThread;
Worker *w = new Worker;
w->moveToThread(t);
bool con;
con = QObject::connect(t, SIGNAL(started()), w, SLOT(start()));
con = QObject::connect(w, SIGNAL(finished()), t, SLOT(quit()));

t->start();
t->wait(); // !!! this causes a problem, if i remove this line the code will work

return a.exec();
}


Worker declaration:


class Worker : public QObject
{
Q_OBJECT

public:
Worker();
~Worker();

signals:
void finished();

public slots:

void start();
void socketConnected();
void socketError();
void socketDisconnected();

private:
QTcpSocket sock;
};

Q_DECLARE_METATYPE(Worker*)

wysota
10th April 2011, 08:03
Tell me what is the purpose of using this thread if you immediately halt the main thread. Why not perform all the work in the main thread then?

mentalmushroom
10th April 2011, 08:26
It is just a test example (I wanted to make it simpler). I need to perform some network operation using several non-blocking sockets, and I need to be able to wait until the thread performing this operations is finished (it is not the only task in the project).

tbscope
10th April 2011, 08:50
When you do not use blocking sockets, there is no need to use a thread.

Your code will become much much more simple if you do not use threads.

I'm not sure what happens in your worker::start function, but if you already make some connections there to another client and wait for some data to arrive, halting the thread is indeed going to give you some problems. You should implement proper logic to handle this.
Which in turn means that it is much more easy to not use threads at all for this.