How to tell if qapplication is running

[midjji]

//In some thread:
{// which should be called the app thread, but is often called the "main" thread, leading to confusion with the thread of int main(){... },
QApplication app; // may be any kind of QCoreApplication derived class....
app.exec();
}

Now somewhere else in some other thread I want to know if the qapp has been created and if exec has been called and if exec has finished.
auto app= QCoreApplication::instance();// gets us the app if any, in the most generic, non thread safe way :(
assert(app!=nullptr);// its not nullptr, so it has been created.

// now what I would want is:
app->startup_completed(); // has the constructor of app finished. Or preferably for the qapplication singleton factory to be thread safe. Its insane that it is not.
app->exec_started(); // has the exec been started and has it not yet finished. Note simply querying the eventloop is not feasible as the eventloop may have hung.
app->exec_finished(); // has exec finished

What I find are:
static bool startingUp(); // non thread safe way to tell if the app is starting up, unclear what this means. Does it mean the constructor is currently beeing called?
static bool closingDown(); // non thread safe way to tell if the destructor is being called? what?

The purpose is writing a generic thread safe qapplication factory, the question is simple, how do I tell if the app is running its event loop?

The earlier answers on this forum to this question are wrong or incomplete.

cheers
//mikael

[ChrisW67]

There should be one, and only one, QCoreApplication (or derivative) in any application. By convention (and usually necessity) this is the very first object created inside the Qt-based application's main() function. The QCoreApplication object is therefore in existence before anything else in the application whether in the principal thread of execution (where all of Qt's GUI exists) or any other you subsequently create. If you use the QThread mechanism to create subsidiary threads, then they are already supplied with suitable event processing infrastructure. Given that, I don't even know what a "thread-safe qapplication factory" is supposed to mean.

Perhaps you could explain what you are trying to achieve and why.

[d_stranz]

Given that, I don't even know what a "thread-safe qapplication factory" is supposed to mean.

Agreed. I read the original post, thought about it a lot, and couldn't come up with any reply because the entire premise doesn't make sense. The Qt framework is based upon there being a single Qt application object instance per running instance of an executable, and trying to create more than one, even if it succeeded, would probably break the application.


assert(app!=nullptr);// its not nullptr, so it has been created.

As soon as a QCoreApplication instance is created, app is non-null.


if exec has been called

-Your application- calls exec(). It isn't mysteriously called from somewhere within Qt, so there is no need to check on it. Nothing really happens in a Qt program until QCoreApplication::exec() is called and the main event loop starts running. Your MainWindow hierarchy might get created (through calls to setupUi(), but nothing actually happens until the call to exec(). You aren't going to receive any signals, no UI or timer events will be issued, no QThread signals will be processed in the main thread even if the threads themselves are started. I am not even sure it is possible to start a QThread running until the main event loop has been started through exec().

Dynamically loaded libraries (DLLs in the Windows world) do not have a QCoreApplication instance; they use the one created by the main executable that loads them. So do QThread instances created by an application.

So it seems like your whole line of questions is based on a misunderstanding of the Qt application architecture. Maybe you are confusing QThread and QProcess? Or confused about QEventLoop, of which there can be multiple instances in an application?