To thread QUdpSocket or to not thread QUpdSocket

[bob2oneil]

I am weighing out the necessity of threading a network interface to my Qt based application. I currently have implemented in the main GUI thread a QUdpSocket, and am depending upon the standard asynchronous call back readDatagram() in response
to the readyRead()SIGNAL from the socket to process content from a separate board connected over a network connection. This activity is currently executing within the main GUI thread.

I need to expand my implementation such that within the readDatagram() function I can dispatch several different types of messages to separate queues with associated worker threads. The message dispatching will be based on signatures of the content of the messages themselves.

I need to have the main GUI thread act in a somewhat synchronous blocking mode when the user picks certain GUI elements. This will require that the application communicate with another board, and only upon receipt of information from this other
board, can the GUI change state. The state change is based on the data received from the other board, which specifies the content dynamically for the next displayed screen.

The GUI then has the behavior of synchronous blocking while this volley of information with the other board is occurring (or a timeout condition occurs).

While this synchronous blocking behavior is occuring, I need to continue to feed other messages from the network dispatcher on to the other "background tasks". These tasks could be used for USB media writes, debug logs, etc.

My concern would be that while my main GUI thread is pending upon a message reception in a blocking manner, the signal handler for reception of additional UDP content would not be timely. I suppose I would have more insight on to whether this could be a potential problem if I knew more of the nature of QUdpSocket and whether it is implemented already as a separate thread through the class derivation to QAbstractSocket to QIODevice. I can not ascertain from inspection of the source code.

I am interested in what type of design would be the most flexible and future safe.

[bob2oneil]

Just to add some clarity to this issue, while I am in the blocking mode awaiting a response to an outgoing command, the UI needs to be locked. This would imply that during the waiting, I could not simply pass messages via the eventLoop.
It would be ok if some user interaction was queued. As a result, I need to come up with a solution that does not allow the UI to change until content is received, and at the same time, background content received over the network will
need to be processed as well as the response to an outgoing command.

[bob2oneil]

Here is some further details on my design requirement.

There will be UDP data sent to an embedded Linux box from two different embedded boards.
On the Linux side, a Qt application will be executing.

The embedded boards are based on Freescale Coldfire processors operating under
the MQX embedded OS. As a result, since I do not control both sides of the link, I can not
take advantage of serial stream concepts such as QDataStream or QTextStream.
The network content will be based in the binary values. A single UDP port number will
be used for communications between the three embedded boards, one Qt on Linux, the others
MQX.

The Main Qt GUI application when it sends an outgoing UDP frame as a command will
wait up to 300 ms for a response. It needs to sent out a duplicate command
every 100 ms for a maximum retry count of 3 in the event a command response is
not detected.

While the GUI thread needs to act blocking during this 300 ms timeframe,
other UDP content received from two embedded boards needs to be processed.

It would seem that the GUI thread command - command response needs to act like
a blocking socket, where a UDP frame is sent, it waits for 100 ms for a response,
sends out a retry, waits more until either the data is received or a timeout occurs.
The main GUI event loop should not allow user input during this timeframe.

The rest of the application threads need to act as a non blocking socket or asynchronous socket.

[bob2oneil]

As I ponder this requirement, I believe I will need a separate thread for the socket interface, where the socket thread will operate in synchronous blocking mode, and will signal the main UI thread upon the reception of a frame for it.
I would use the thread safe signal slot mechanism, and perhaps mutex read writer locker protection on the queue where data will be written by the socket thread, and read by the Main GUI thread. The main GUI thread would
pend on a semaphore or condition or a timeout condition. This would lock the GUI thread as intended, but allow the socket thread to continue dispatching received messages. If anyone has additional thoughts on this, I would
be interested in your opinion.