Hi, You can connect the "finished()" signal to a slot and there check if all threads are not running. I assume that you have a list of threads.

@pauledd I would recommend using the build-in QThread mechanism to interrupt a thread: public slots: void doWork() { forever() { ... if ( QThread::currentThread()->isInterruptionRequested() ) { return; } ... } } You can add this check to your SPI loop multiple times but avoid to call it too often, according to the dokumentation. Add something like this to your MainWindow-Instance: public slots: void cancel() { if( thread.isRunning()) { thread.requestInterruption(); } } and connect this Slot to some Cancel-Button.

@VRonin Thank you, it works perfectly. I thought that ‘this’ could not be called inside a thread.

@diverger As @micland already explained this does not have anything to do with Qt. It is a general problem with multi-threading: if you call a method from an object which leaves in another thread then you have to make sure this does not cause any problems.

@mbruel said: What do you think, still something to avoid? You do want to free your resources, while this is usually done in the destructor, that might not always be the case (for example QFile has open() and close() methods, and internal state that it tracks. For speed optimisation and avoiding signal/slots when possible, well I don't know... I'm new to async programming and still don't really see the point to use a signal/slot mechanism with direct connection instead of directly calling the function on the object. It might not optimize a lot but it should definitely avoid few functions calls and passing by the event queue. When you connect objects that live in the same thread, you don't have any event queue calls (it's a direct connection, and behaves exactly like you've invoked the function yourself). A reason why you might want to use signals and slots, instead of pure function calls is to decouple components, which is something you'd want for the most part. I'm wondering if the impressive results of the QT version are due to the C++ and use of native socket or more of the non blocking sockets. Probably both, although internally (at the OS level) the sockets are blocking, you just don't see it. Also linux sockets, at least to my experience, tend to perform better than their windows counterparts. I don't know why, they just seem to be faster.

I'm having a new problem when I move a second QTcpSocket inside the thread. Everything seems to work fine but the thread is crashing (segmentation fault) after deletion (after receiving the destroyed signal). It seems to be an desallocation issue... I couldn't manage to figure out the problem yesterday and today... I'm going to write a easier example of my architecture and open a new post. Cheers

Yep, you can move as many objects you want in a single thread.

@sinjohr I think this things happen. Working with threads is not always a cool path. According to the documentation, a QEvent::ThreadChange event is sent to the object just before the thread affinity is changed. You can try to handle the event. Another option is using the overloaded method void QCoreApplication::postEvent(QObject * receiver, QEvent * event, int priority) and use Qt::LowEventPriority.

Ok great, thanks a lot for your answers, that's now completely clear :-).