QMetaObject::invokeMethod with Qt::BlockingQueuedConnection just got stacked how can i know why ?
-
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();
......@
-
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.
-
yeah but i need to know when the method finished , in multi -thread app
is there other way ?
-
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.
-
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?
-
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
-
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 ?
-
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.
-
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 ?
-
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.
