Skip to content
  • 0 Votes
    5 Posts
    2k Views
    O
    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.
  • 0 Votes
    7 Posts
    3k Views
    MCamM
    @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.
  • Creating QThread from another QThread

    Solved General and Desktop qthread movetothread
    9
    0 Votes
    9 Posts
    3k Views
    C
    @VRonin Thank you, it works perfectly. I thought that ‘this’ could not be called inside a thread.
  • About Qt::DirectConnection

    Unsolved General and Desktop thread connect movetothread
    7
    0 Votes
    7 Posts
    7k Views
    jsulmJ
    @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.
  • 0 Votes
    10 Posts
    8k Views
    kshegunovK
    @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.
  • 0 Votes
    10 Posts
    10k Views
    mbruelM
    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
  • 0 Votes
    11 Posts
    6k Views
    M
    Yep, you can move as many objects you want in a single thread.
  • 0 Votes
    2 Posts
    1k Views
    T
    @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.
  • MoveToThread and QTimer

    General and Desktop movetothread qthread
    12
    0 Votes
    12 Posts
    17k Views
    T
    Ok great, thanks a lot for your answers, that's now completely clear :-).