Results 1 to 20 of 26

Thread: Main thread - worker thread communication.

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,368
    Thanks
    3
    Thanked 5,018 Times in 4,794 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Main thread - worker thread communication.

    If you force queued connections, then all will be ok. The thing that makes me sure my approach will work is that the "emit" object is created (and thus handled) in the worker thread (because it's created in the run() method that is executed in context of the worker thread). This means that if I call a method that emits a signal and both the caller (run()) and the callee (Emit instance) are in the same (worker) thread, I can be sure that the signal will be queued because the receiver is in the GUI thread. Now if the callee (QThread object) was in a different thread than the caller (run()) I don't know how Qt would behave. You can check Qt sources and see for yourself - maybe the trick I made was not needed. You can also have the same effect without the Emit object - just move the QThread object to the thread it represents.

  2. #2
    Join Date
    May 2007
    Posts
    23
    Thanks
    3
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: Main thread - worker thread communication.

    Quote Originally Posted by wysota View Post
    If you force queued connections, then all will be ok. The thing that makes me sure my approach will work is that the "emit" object is created (and thus handled) in the worker thread (because it's created in the run() method that is executed in context of the worker thread). This means that if I call a method that emits a signal and both the caller (run()) and the callee (Emit instance) are in the same (worker) thread, I can be sure that the signal will be queued because the receiver is in the GUI thread. Now if the callee (QThread object) was in a different thread than the caller (run()) I don't know how Qt would behave. You can check Qt sources and see for yourself - maybe the trick I made was not needed. You can also have the same effect without the Emit object - just move the QThread object to the thread it represents.
    Ok, i see...very helpfull post indeed. The "queued connections", as i saw it, are a very nice way to keep things simple and not complicated. regarding the Singals and Slots mechanism and the communication over different threads. (In fact, i like it even more that the respective C# stuff)
    Is there any "catch" with that ? Performance problems or something else ?
    Software Engineer, riding a Kona King Kikapu 2007

  3. #3
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,368
    Thanks
    3
    Thanked 5,018 Times in 4,794 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Main thread - worker thread communication.

    They are a bit slower as you have to serialise all the arguments and then recreate them back in the other thread when the slot is executed. And there is of course the latency between emiting the signal and the other thread processing it. Oh... and the other thread has to have an event loop running of course.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Qt is a trademark of The Qt Company.