CODEWITHSUNDEEP
c++qtzeromq
Aminos
Aminos

Reputation: 871

Communication with a permanent thread handling ZeroMQ with Qt

I have a class that inherits from QThread and that handles a ZeroMQ SUB subscribe socket in a while loop ( polling in the thread's run method ) and notifies the GUI thread by emitting signals when receiving messages from the socket.

In this QThread derived class, before the polling loop, I also create a ZeroMQ PUB publish socket and there are methods to use it. These methods are only used in the main thread ( GUI ) to send data to the server.

This solution works without any problem, but it's not perfect. I want only one thread to handle both subscribe and publish sockets operations. The GUI thread ( main ) instead of calling a QThread derived class method, will send a signal to request publishing a data.

Is there a nice pattern, based on Qt tools, to implement that ?

Upvotes: 0

Views: 621

Answers (2)

Aminos
Aminos

Reputation: 871

In a QObject, I can use a QTimer to handle subscribe socket's polling and some signal/slots to handle publish socket but also configuring subscribe socket in a thread-safe manner. A QTimer isn't really necessary, I can have ab infinite loop and at each iteration call :

QThread::currentThread()->eventDispatcher()->processEvents(QEventLoop::WaitForMoreEvents);

to process received signals.

Upvotes: 0

user3666197
user3666197

Reputation: 1

Is there a nice pattern, based on Qt tools, to implement that ?

Well,

ZeroMQ part has no problem to handle both PUB and SUB at once

Independently of the primary motivation, the ZeroMQ engine is not the issue here. If looking inside wires and details, ZeroMQ Context() instances are actually pools-of-threads, which provide lot of opportunities for performance tuning and respective prioritisations, mapping socket-instances onto directly-mapped groups of ZeroMQ I/O-threads.

If not working with ZeroMQ day by day, one may enjoy a 5-seconds read into the main conceptual differences, as sketched in brief in the [ ZeroMQ hierarchy in less than a five seconds ] Section.

This said, the main concern is on how one would like to require the Qt-ecosystem to "speak" through the ZeroMQ infrastructure. Given a pure non-blocking, well designed code is put into the piping, there would be no major barrier to let ZeroMQ send and collect signals across the platform.

Efficiency of message passing, (ultra)-low-latency and zero-copy mechanics are handy and available at your fingertips. This means, that bad idea or a nasty code will remain being bad or nasty, where the ZeroMQ framework cannot be blamed for "making troubles" :o)

Upvotes: 1

Related Questions