Blocked waiting for a asynchronous Qt signal

Question

I know, there are some similar questions to the following out there, but I couldn't find a concrete answer that helps me. So here's my problem:

I work on an application that does some gui-initialisations on start up. One of the things I have to do, is calling

NetworkConfigurationManager::updateConfigurations ()

This is a asynchronous call, which emits the updateCompleted() signal, when it is finished. The problem is, that all my other gui-initialisations have to wait until the updateConfigurations() is finished.

So what I could do would be something like this:

MyApp::MyApp(QWidget *parent) : ....
{
   doSomeInits();
   //Now connect the signal we have to wait for
   connect(configManager, SIGNAL(updateCompleted()), this, SLOT(networkConfigurationUpdated()));
   configManager->updateConfigurations(); //call the async function
}

void MyApp::networkConfigurationUpdated()
{
   doSomething();
   doRemainingInitsThatHadToWaitForConfigMgr();
}

To split up the initialisation doesn't seem a good way to me. I think it makes the code much harder to read - inits should remain together. The other thing is: Because updateConfiguration() is asynchronous, the user will be able to use the GUI, which doesn't give him any information yet, cause we are waiting for updateCompleted().

So is there a way to wait for the updateCompleted() signal, before the application continues?

like:

MyApp::MyApp(QWidget *parent) : ....
{
   doSomeInits();
   //Now connect the signal we have to wait for
   connect(configManager, SIGNAL(updateCompleted()), this, SLOT(doSomething()));
   ???? //wait until doSomething() is done.
   doRemainingInitsThatHadToWaitForConfigMgr();
}

In some APIs there are blocking alternatives to asynchronous functions, but not in this case.

I appreciate any help. Thanks!

score 27 · Accepted Answer · edited Sep 13 '17 at 04:25

27

The way to do this is to use nested event loops. You simply create your own QEventLoop, connect whatever signal you want to wait for to the loop's quit() slot, then exec() the loop. This way, once the signal is called, it will trigger the QEventLoop's quit() slot, therefore exiting the loop's exec().

MyApp::MyApp(QWidget *parent) : ....
{
    doSomeInits();
    {
        QEventLoop loop;
        loop.connect(configManager, SIGNAL(updateCompleted()), SLOT(quit()));
        configManager->updateConfigurations(); 
        loop.exec();
    }
    doReaminingInitsThatHadToWaitForConfigMgr();
}

edited Sep 13 '17 at 04:25

Maxwell175

1,954
1
17
27

answered Aug 24 '10 at 12:45

chalup

8,358
3
33
38

Yes, this works, and it's the standard pattern for "blocking wait without blocking the UI". I would avoid it though if possible. Nested event loops can cause serious headaches, e.g. the user doing random unforseen stuff while loop.exec(), quitting the application etc., leaving the application in an unforseen, inconsistent state after exec() returns. Or: An (user) event opens another local event loop waiting for an event which requires the first loop to finish, causing kind of a quasi-deadlock. That's why I recommend to use a slot and continue there, even if that is more verbose. – Frank Osterfeld Aug 24 '10 at 13:33
First of all: thanks for your help. Your answer is right, although it is not working in my solution. I guess I have one of the problems mentioned by Frank, cause my loop is unable to quit. Nevertheless I found a proof to your answer in the Nokia Wiki (http://wiki.forum.nokia.com/index.php/TSQ001335_-_Asynchronous_operations_in_S60_and_Qt) . So thank you all! – cyphorious Aug 24 '10 at 13:41
According to Qt/Nokia, you should not use a QEventloop as it my cause out of control recursion (see http://developer.nokia.com/community/wiki/How_to_wait_synchronously_for_a_Signal_in_Qt). This should be for testing only. Or am I misreading this article? – TSG Aug 17 '14 at 15:30
This answer is handy for writing automated test cases, thanks! – vpicaver Sep 02 '16 at 12:22
Frank is right - the QEventLoop method is dangerous. I found this out the hard way. I have an app that needs to fetch several webpages and in the correct order, and the logic got really nasty bouncing from function to function in a state machine so I tried using QEventLoop. Well when I did that, if the user was moving the window (or certain other things) with the event loop going, the window focus would get lost. The whole app would freeze. ALL apps would freeze! Hitting alt-tab was the only way to get control back and then it would run normally again. So yeah... it's not a good solution. – Ph0t0n Mar 01 '18 at 04:33

score 7 · Answer 2 · edited May 23 '17 at 12:26

Working from chalup's answer, if you are going to be waiting for a user-noticeable time, you might want to show a progress bar instead (or a splash screen, perhaps).

MyApp::MyApp(QWidget *parent) : ....
{
    doSomeInits();
    {
        QSpashScreen splash;
        splash.connect(configManager, SIGNAL(updateCompleted()), SLOT(close()));
        configManager->updateConfigurations(); 
        splash.exec();
    }
    doReaminingInitsThatHadToWaitForConfigMgr();
}

score 2 · Answer 3 · edited Feb 03 '17 at 08:27

2

Another solution could be to use QSignalSpy::wait(). This function was introduced in Qt 5 and does exactly what you want.

The only problem I see with that class is that it is provided in the QtTest module. In my case I find it very useful when testing code, but it might be not the best solution for production code.

edited Feb 03 '17 at 08:27

qris

7,900
3
44
47

answered Jan 05 '17 at 13:34

piponazo

478
2
4
10

Seems to internally be the same as `chalup`'s answer. – Maxwell175 Sep 13 '17 at 01:54

Blocked waiting for a asynchronous Qt signal

3 Answers3

Linked