To thread QUdpSocket or to not thread QUpdSocket

[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.