Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Threading question(s)



  • Hello,
    recently I started using QT for some cross platform development targeting mainly Linux and Android.

    One of the most painful things to me with QT is how to use threads (properly). Now, I found some fine articles, like infamous How to really truly use qthreads. Up until now, I used pthread/windows threads wrappers, where I was free to start thread and give it object's (private) member method to be executed. Notification of other object was via callback (in case of a need), but it was rarely necessary, since threading objects was 'active': holding thread handle and 'join' when object is about to be deleted (in destructor).

    QT is forcing different policy of usage, and quite frankly I am struggling to get a grasp on it and will try to explain this through an example of what I need to implement:

    I am creating libssh2 tcp forwarder. Part of this forwarder should be a thread that will try to connect to the given SSH server/port combination. This thread starts initially and loops until connection is successful or parent object dies (ie application is closed or cancel is issued). Same pattern should apply in case QTcpSocket disconnects. So, in short - thread should be 'alive/active' only in case there is no connection. Now main confusing part for me is: should I use one thread, which is bound to parents lifecycle (member variable) or to start another each time (re)connect is needed? Second (and more important), when 'connector' thread manages to connect, it must use slot in parents object to notify it about the 'connect' event; but tbh I don't like this since slot is like public method and this looks like breaking OOP model (I'd prefer this thread is actually private member of the class itself) . In case I must use slot at the end, shall Qt::QueuedConnection be used when connecting objects, to prevent usage of internal locks and stuff? I can use semaphore combined with state member to drive one thread and use either callback or signal/slots- but is it the 'QT way'?

    As a side question; is it possible to uses Conan C++ with QT Creator?

    Any suggestions are more than welcome.

    Thank you all in advance


  • Moderators

    should I use one thread, which is bound to parents lifecycle (member variable) or to start another each time (re)connect is needed?

    Since the thread is only necessary to try to connect I would create them as needed and destroy them when done. No sense in having your application eat up a bunch of threads on the system that it isn't using most of the time.

    it must use slot in parents object to notify it about the 'connect' event; but tbh I don't like this since slot is like public method and this looks like breaking OOP model (I'd prefer this thread is actually private member of the class itself)

    Slots do not need to be public, make it private if you like.

    class Something : public QObject
    {
       Q_OBJECT
    
    public slots:
       void myPublicSlot();
    
    protected slots:
       void myProtectedSlot();
    
    private slots:
       void myPrivateSlot();
    };
    

    but is it the 'QT way'?

    There isn't necessarily a "Qt way" when it comes to threading. You can do a more traditional approach to threading and subclass QThread implementing a run function and handling event loops manually. Or you can use moveToThread() and have Qt do it for you via signals and slots. There's also QRunnable which is like a fire and forget type thread for specific tasks. And you could use pthreads or c++ threads if you wanted. It's not like they won't work with Qt.



  • Thank you very much!


Log in to reply