8

[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 "(.. (..))"?

Community
  • 1
  • 1
jrharshath
  • 25,975
  • 33
  • 97
  • 127

3 Answers3

13

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.

Bill
  • 14,257
  • 4
  • 43
  • 55
  • still there remains one thing: if the main event loop is busy getting events from the system, who is generating them? how is the `newConnection()` signal ever emitted, if the main loop is busy waiting in this loop? – jrharshath Sep 25 '09 at 05:02
  • @harshath.jr - I haven't used QTcpServer before, but from the documentation it looks like it asks the OS to deliver Tcp events to your program. When your program processes that tcp event, the QTcpServer does what it needs to, then emits newConnection(). – Bill Sep 25 '09 at 15:38
0

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.

Georg Fritzsche
  • 97,545
  • 26
  • 194
  • 236
0

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.

JimDaniel
  • 12,513
  • 8
  • 61
  • 67