TcpSocket in a different thread

Hi all,

I have a MainWindow class, which instantiates a 'Connector' class. The Connector is responsible for making TCP socket connections, and reading data and putting into a shared buffer.

The data read from the TCP socket is to be processed by some method in the MainWindow class. My concern is, while the main window is processing with the data, further signals from the TCPSocket (data ready) might be lost, as the event loop of 'Connector' is blocked.

So I want to push the 'reading of data' from the TCPSocket to a different thread so that the event loop is not blocked while processing of data is going on.

How do I achieve this ? Should I use runnable or qthread ?

The Connector looks like this :

Code:

---

public :
    Connector(QString hostname, quint16 port, TemanejoMainWindow* p);
    ~Connector();
 
public slots:
    void getError(QAbstractSocket::SocketError);
    void readData();
    void connectToHost();

---

The constructor binds the signals and slots as :

Code:

---

tcpSocket = new QTcpSocket(this);
 
connect(tcpSocket,SIGNAL(error(QAbstractSocket::SocketError)), this,
                     SLOT(getError(QAbstractSocket::SocketError)));
 
connect(tcpSocket, SIGNAL(readyRead()), this, SLOT(readData()));

---

The method "connectToHost" makes the TCP connection, while readData() is executed everytime data is ready to be read. To me, pushing readData
method to a new thread makes sense.

Any help on how to do this ?

Best regards

Quote:

---

The data read from the TCP socket is to be processed by some method in the MainWindow class. My concern is, while the main window is processing with the data, further signals from the TCPSocket (data ready) might be lost, as the event loop of 'Connector' is blocked.

---

Why do you think this?

As I understood from here :

http://qt-project.org/wiki/Threads_E...980b572877aa84

Quote:

---

The data read from the TCP socket is to be processed by some method in the MainWindow class. My concern is, while the main window is processing with the data, further signals from the TCPSocket (data ready) might be lost, as the event loop of 'Connector' is blocked.

---

While the main window is processing the data, further signals are blocked (if you want to call it so), but are not lost. TcpSocket Signals will be processed once the main window is done with processing.

Ok. So separating the network connector to a different thread doesn't help in anyway, e.g. responsiveness or performance ? (The main GUI thread will be doing a lot of processing alongside.)

Secondly, if I separate the network component to a different thread, what is the best way to communicate with the main GUI thread ? Via a shared buffer or a queued signal slot connection ?

You can use queued signal, or you can use a combination of both. eg. you emit a signal indicating that data is avaiable in shared buffer.

IMO it has to depend on what kind of data you want to send, how often you send, do you expect ack back from ui etc (a more of a design decision).

See if someone else has other suggestions.

Quote:

---

Originally Posted by gaganbm

Ok. So separating the network connector to a different thread doesn't help in anyway, e.g. responsiveness or performance ?

---

It depends. If you process data for a long time and there is much more data coming in then eventually you will fill the input buffer and TCP will block the sending party from sending more data so the communication will become slower. But you can do the processing in a worker thread which will prevent both the GUI and networking from freezing.

Quote:

---

Secondly, if I separate the network component to a different thread, what is the best way to communicate with the main GUI thread ? Via a shared buffer or a queued signal slot connection ?

---

Signals and slots. But the best way is to do networking in the main thread and processing in an extra thread.