Run multiple QEventLoops in parallel (for QtNetwork)

Question

I try to extend an old program that runs under Ubuntu/Linux Desktop with a Qt-network support. Having a LAN communication with these libraries needs to run the .exec() of the QEventLoop to really start working (i.e.: accept connections, receive, send, etc.)

The problem

Well the problem is I don't know where this event loop is in the main program and because I vaguely know about it's design I prefer a solution that is as indipendent as possible.

My idea

I already checked I don't need the main-QEventLoop, and it's alright to make another one just for the networking (i.e. nesting). Unfortunately I can't figure out how to run both loops in parallel, since my program stops at the nested-.exec() and so the main program is on halt too.

So my main intention is actually to extend the main program with a Qt-Networking, I'm open for other solutions too.

@KubaOber yes you were perfectly right. If you make this an answer I'd mark it as a solution. — user3085931, Mar 11 '16 at 08:19

score 2 · Answer 1 · answered Mar 02 '16 at 10:54

2

I would suggest to use a QThread if you are in need of running 2 independent event loops.

answered Mar 02 '16 at 10:54

Paraboloid87

428
2
14

is it guaranteed then that my incomming connections will be accepted (by the signal/slot procedure), or may it be that a request gets lost because the thread was not running at that time ? – user3085931 Mar 04 '16 at 08:26
1

You have to make sure that the thread is running. Objects 'living' in the thread will not be triggered, if the thread is not running. For that reason you should create the thread, move the object to the thread and start the thread. Then you can establish your connection. – Paraboloid87 Mar 04 '16 at 12:04

score 1 · Accepted Answer · answered Mar 11 '16 at 14:34

Is the main program interactive? If it is, then likely it runs the glib main event loop. Qt uses the same event loop on Linux, so you don't need to call exec() in your code. Prime the event loop only once by creating an instance of QEventLoop, posting a quit call to it, and exec() ing it. Then return control to the main program. Your code will still run as events arrive (timers time out, network packets arrive, etc.).

The wonderful thing about native event loop integration that you get with Qt is that you don't need to do the main exec() if someone else is spinning the loop already.

So, here's how a Qt plugin to a GTK application on Linux might look like:

extern "C" void pluginInit() {
  new QApplication;
  QEventLoop loop;
  QMetaObject::invokeMethod(&loop, "quit", Qt::QueuedConnection);
  loop.exec();
}

extern "C" void pluginDestroy() {
  delete qApp;
}

Once the plugin user calls pluginInit, they can invoke any function in your plugin that uses Qt, and the events will be properly processed by the invoking application's event loop.

I'd prefer such a solution compared to threading, since it sounds more stable in general.

If threading is unstable for you, you're not doing it right. Networking support will run great on a dedicated thread. It's probably one of the few legitimate uses for a second thread, since that way your network data processing won't be delayed by the sweet time the userland renderer and compositor takes to put together what you see on the screen.

Works like charm. I had never thought of using `invokeMethod(...)`. Thank you very much — user3085931, Mar 16 '16 at 08:06

Run multiple QEventLoops in parallel (for QtNetwork)

2 Answers2