Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QMetaObject::invokeMethod with Qt::BlockingQueuedConnection just got stacked how can i know why ?
Forum Updated to NodeBB v4.3 + New Features

QMetaObject::invokeMethod with Qt::BlockingQueuedConnection just got stacked how can i know why ?

Scheduled Pinned Locked Moved General and Desktop
10 Posts 3 Posters 7.7k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • U Offline
    U Offline
    umen242
    wrote on last edited by
    #1

    I have thread that is running fine in parallel to the main thread , its job is to collect data and populate it to the main view widget
    every thing worked fine , until i added another QMetaObject::invokeMethod method into the thread . with Qt::BlockingQueuedConnection , the reason i set Qt::BlockingQueuedConnection is that i need to know when the method has finished.
    but when the thread enterd into this function every thing stacked and the slot im calling never reach.
    i have no idea how to check what is the problem . basclly i have 2 functions one under the other like this :

    @ bool bReturnInvokeGroupsLastUpdate = false;
    bool bInvokeMethod1= QMetaObject::invokeMethod(m_pApi,
    "GetGroupsLastUpdateTimeSlot",
    Qt::BlockingQueuedConnection,
    Q_RETURN_ARG(bool, bReturnInvokeGroupsLastUpdate),
    Q_ARG(QStringList, groupsMarkedForUpdate),
    Q_ARG(QVector<StringPer>*&, m_batchVectorResult),
    Q_ARG(int,type));
    .....
    .....
    .....
    ....
    if(bReturnInvokeGroupsLastUpdate )
    emit UpdateMainWallNotifications();

     // THIS METHOD GOT STACKED
     bool bReturnInvokeFriendsLastUpdate = false;
    bool bInvokeMethod2= QMetaObject::invokeMethod(m_pApi,
         "GetFriendsLastUpdateTimeSlot",
         Qt::BlockingQueuedConnection,
         Q_RETURN_ARG(bool, bReturnInvokeFriendsLastUpdate),
         Q_ARG(QStringList, friendsMarkedForUpdate),
         Q_ARG(QVector<StringPer>*&, m_batchFriendsVectorResult),
         Q_ARG(int,type));
    

    ......
    ......
    ......
    if(bReturnInvokeFriendsLastUpdate)
    emit UpdateMainWallNotifications();
    ......@

    1 Reply Last reply
    0
    • T Offline
      T Offline
      tobias.hunger
      wrote on last edited by
      #2

      Oh, invokeMethod seems to be very en vogue during the last couple of days. Are you guys sure you are doing the right thing here? QMetaObject::invokeMethod is mostly needed as infrastructure for the signal/slot system and I hardly ever needed to use it directly.

      Just connect() properly and emit signals.

      1 Reply Last reply
      0
      • U Offline
        U Offline
        umen242
        wrote on last edited by
        #3

        yeah but i need to know when the method finished , in multi -thread app
        is there other way ?

        1 Reply Last reply
        0
        • T Offline
          T Offline
          tobias.hunger
          wrote on last edited by
          #4

          That sounds seriously broken to me. Why do you need to couple these threads so closely? Maybe putting the functionality into one thread would work better?

          Usually you have the UI thread which does all the UI rendering and user interaction and worker threads which collect data and signal the UI thread about changes, processed data, etc.

          1 Reply Last reply
          0
          • A Offline
            A Offline
            andre
            wrote on last edited by
            #5

            I agree with Tobias: your design sounds broken. If you do want to get a message back in the worker thread, why not give the worker thread a slot to receive these messages and let the main thread emit such a message?

            1 Reply Last reply
            0
            • U Offline
              U Offline
              umen242
              wrote on last edited by
              #6

              its 1 thread that is contains the 2 QMetaObject::invokeMethod's
              not few threads . its only main thread and this thread that contains the 2 functions

              1 Reply Last reply
              0
              • U Offline
                U Offline
                umen242
                wrote on last edited by
                #7

                Andre And Tobias thanks for taking the time to answer
                Andre:
                but i need to know when the function in the main thread is finished so i could continue with the fllow
                how can it be done with pure SIGNAL/SLOT , where the main thread will signal the running thread when finish ?
                from what i read only way to wait is to use :Qt::BlockingQueuedConnection
                what im missing here ?

                1 Reply Last reply
                0
                • T Offline
                  T Offline
                  tobias.hunger
                  wrote on last edited by
                  #8

                  It looks like you have one thread collect IM status and another (most likely the UI thread) do something with it.

                  Why would you want to block the status thread while the UI is updating? The whole point of using a thread is to have it not block while other threads are doing their work. Why don't you just pass the data on and are done with it? If you really need to do so then maybe it would make sense to just merge the two threads into one, using asynchronous programming to make sure to not block for too long.

                  This is of course just guesswork, based on the little information you provided.

                  1 Reply Last reply
                  0
                  • U Offline
                    U Offline
                    umen242
                    wrote on last edited by
                    #9

                    so if i understand you right .
                    the thread should collect the input and set it into main structure no matter what , and the main thread should always check this structure if there is data in , and if true . will update the main GUI ?
                    This is what you meant ?

                    1 Reply Last reply
                    0
                    • T Offline
                      T Offline
                      tobias.hunger
                      wrote on last edited by
                      #10

                      Yes, usually you have a worker thread that does something (interact with the network, calculate something, etc.) and have it signal updates to the UI thread (incl. required information if copying them is not too costly or otherwise some handle to retrieve the relevant data) and then have it update the UI accordingly. This is "fire and forget": The worker fires a signal and then proceeds as normal. The receiver is responsible for making sure it is acted upon. There is no need to block the worker thread while the UI is updated.

                      Of course you only signal when something actually happened.

                      If you need to block the worker thread because you need feedback from the UI which can't be done via signals emited by the UI thread then you might be better of not have a worker thread in the first place. You can always use event-driven programming to asynchronously process network requests, etc. which will also keep your UI responsive.

                      1 Reply Last reply
                      0

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved