MyLibraryWrapper

#include \
#include \
#include \

With this in mind, I intend to have secondary threads NOT running an event loop so they will pend when not performing useful work. The secondary threads will signal the main GUI thread which is running and event loop via a signal. The secondary threads may communicate with each other, perhaps send heap allocated messages to other threads not running an event loop, but in this case, will not use the signal method.

Let me clarify why the UI needs to act blocking (but perhaps not actually be blocking). The UI presents a view of content from a separate embedded board. What is displayed in the UI represents a view upon data on the embedded board that is shared over a network connection.

The content of the GUI will be dynamic, such that when the user picks a particular GUI screen element, a volley of UDP messages with the embedded board will occur to define what will be made visible on the next displayed screen.

My application acts to a large extent like a modern cellphone driving purely by a touchscreen under embedded Linxu (e.g. kinectic scrolling lists, icon views, multiline list controls, swipe navigation, etc.) As such, there are 4 off touchscreen buttons that the user could press, their is a popup context menu when the user can make selectoins, etc. While the volley is occurring, all user navigation needs to be prohibited.

But your response has me thinking, that maybe there is a better way to a act blocking, without actually blocking the event loop of the GUI thread.

Perhaps I can find a convenient way of setting some form of flag or signal or semaphore that would be set when an outstanding communications session is underway, and block all user activity (or perhaps queue it) while this is occurring. If you have some thoughts on this type of implementation, I would be interested.

I always believe in the KISS principle (Keep it simple stupid), and perhaps I am making it more complex than it warrants.

In the 10+ years I’ve been designing user interfaces, I have *never* seen a good reason to block the event loop like that. That seems like a mis-requirement. It’s one thing to prevent user input for a period of time, but blocking the event loop is something altogether different, and ill-advised in my opinion.

It is *highly* unlikely that QUdpSocket uses multi-threading under the hood. It probably uses non-blocking socket I/O.

–Dave

I have read the many comments on the “your doing it wrong” thread, and there seems to be varying opinions, perhaps some not too happy to learn they are not using what is considered best practices — but I do not see a consensus.

One sort of unique requirement that I have is that I actually need to block my UI thread while it is retrieving data (or a timeout occurs of 300 ms), while the UDP dispatcher, presumably in another thread, feeds content to other worker threads. Where I need some clarity is perhaps understanding more the nature of the QUdpSocket implementation under the covers. I think it safe to say that if it is being used in asynch mode, then an event loop would be absolutely necessary. I would also want to take advantage of the thread safe signalling using invokeMethod() as you have described in your blog.

I am not as sure of this requirement when it is being used in blocking mode. There is a suggestion from what I have read on QUdpSocket that perhaps QUdpSocket operates in its own thread already, but I can not ascertain that from casually looking at the Qt source code.

QThread *myUdpThread = new QThread();
myUdpThread->start();

QUdpSocket *socket = new QUdpSocket();
socket->moveToThread(myUdpThread);

connect(socket, SIGNAL(readyRead()), …

And that should move all UDP socket processing to the separate thread, and you can reveive its signals from your main thread (if that’s what you want).

If you want to handle the data read from the socket in the separate thread, you’ll have to do something like this:

class MyDataProcessor : public QObject {
Q_OBJECT
public slots:
void readyRead() {
// do something here
}
};

MyDataProcessor *processor = new MyDataProcessor();
processor->moveToThread(myUdpThread);

connect(socket, SIGNAL(readyRead()), processor, SLOT(readyRead()));

–Dave

I have not yet adopted the “you’re doing it wrong” sublcass avoidance in my QThread code. I am still sub-classing QThread. However, it seems that in order to call exec() (which is a blocking call for the life of the event loop you are creating), you *must* sub-class QThread, reimplement the run() method, and call exec() in your run() method.

I don’t see any way around sub-classing QThread if you want your thread to have an event loop.

Now, you only *need* an event loop if you are receiving signals, and not necessarily if you are only emitting them (double check me on that though). However, many classes require an event loop to function properly. It’s likely QUdpSocket will need an event loop running in order for it to function properly.

You really should experiment with this though, as I haven’t done it (yet).

–Dave