I know that similar questions have been asked on this and other forums so don't bother with that response. None of them address my specific question.

I have an application that communicates with an embedded processor through a serial interface. The data words are of variable but known data patterns

I can open and read and write to the serial port just fine. Commands are sent to the serial port and data is read in response.

My problem is that the embedded microprocessor does not respond to commands with the same response time. One command may only take milliseconds and another may take 2 seconds or more. That part is not within programmatic control.

My problem is that I do not want an asynchronous read to block the GUI. For instance if a command is issued that takes 2-3 seconds to respond, the main thread does one of two things.

1) When using a blocking approach. the application stalls waiting on the readyRead() signal.
2) Using the non-blocking approach the application is much more responsive but has data from multiple commands intermixed.

So, I think I know the answer to this problem but I seek the wisdom of the group. I think the probable answer would be to use a circular buffer and just wait for a readyRead() to dump data into it. In a separate process, evaluate the data and call the appropriate function to respond.

The problem with this approach is that commands may be issued before the last response is complete.
For instance, cmd1 is issued and it takes 2.5 seconds to respond and unload data. Before the response and data download has completed a new command (cmd2) is issued. The new command my have a quicker response time (700ms) than the older and longer responding command. That means that the data from the second command my be interleaved with the first.

So how does one handle the command / response mixture?