Qt signals and slots, threads, app.exec(), and related queries

Question

[related to this question]

I wrote this piece of code to understand how qt signals and slots work. I need someone to explain the behaviour, and to tell me if I'm right about my own conclusions.

My program:

connectionhandler.h

#ifndef CONNECTIONHANDLER_H
#define CONNECTIONHANDLER_H

#include <QTcpServer>
class ConnectionHandler : public QObject
{
    Q_OBJECT
public:
    ConnectionHandler();
public slots:
    void newConn();
private:
    QTcpServer *server;
};

#endif // CONNECTIONHANDLER_H

connectionhandler.cpp

#include "connectionhandler.h"
#include <QTextStream>

ConnectionHandler::ConnectionHandler() {
    server = new QTcpServer;
    server->listen(QHostAddress::LocalHost, 8080);
    QObject::connect(server, SIGNAL(newConnection()),this, SLOT(newConn()));
}
void ConnectionHandler::newConn() {
    QTextStream out(stdout);
    out << "new kanneksan!\n";
    out.flush();
}

main.cpp

#include <QCoreApplication>
#include "connectionhandler.h"

int main(int argc, char* argv[]) {
    QCoreApplication app(argc,argv);
    ConnectionHandler handler;
    return app.exec();
}

Now, running this program sends it into an infinite loop looking for new connections.

Observation: if I don't call app.exec(), the program returns immediately (as it should).
Question: why?

Question: if I had connected the slot as a queued connection, when would the slot invocation be performed?
Question: if app.exec() is an infinite loop of sorts, how does the newConnection() signal ever get emitted?

Big Question: Is their any "second thread" involved here? (I expect a no, and a stunningly elegant explanation :) )

Thanks,
jrh

PS: who else has this nested parenthesis syndrome? like "(.. :))" or "(.. (..))"?

Answer 1

If you don't call app.exec() then the program hits the end of your main() and ends. (Why? There's no more code to execute!)

app.exec() is an infinite loop of the following style:

do
{
  get event from system
  handle event
}
while (true);

If you use a queued connection, then the event is added to your event queue, and it will be performed at some point in the future during the app.exec() loop.

There is no second thread in your program. Events are delivered asynchronously by the OS, which is why it appears that there's something else going on. There is, but not in your program.

Answer 2

app.exec() enters the main event loop and waits until exit() is called.

update:
The main event loop and the glue code generated by qmake take care of transferring the event message from the QTcpServer to your ConnectionHandler.

If you'd use queued connections the actual connection to the QTcpServers slot would be delayed until the main event loop delivers the connection request.

Answer 3

When you say it enters an infinite loop, you mean it crashes the program?

Because listen() will become part of the main application event loop the way you have it set up, which runs until you exit the program. I'm not sure what the problem is. There should be no trouble of your signal being emitted in the main application event loop (exec()) whenever one is encountered.

If you like, you could have your ConnectionHandler class extend QThread and run listen() in it's own thread, apart from the main application loop.