That does not really fit your application.
Your current backend is already asynchronous and any future backend has a likely chance of also being asynchronous (e.g. network based).
As a GUI you are not in a situation where you can just block and wait for response, that would result in bad user experience.
It will if there is something to return.
Which is not likely in the pseudo code above since that would require that the data has been written to the child process, then your process having been suspended long enough for the child to process and write back before your program has had a chance to resume and call read.
Not impossible, but highly unlikely.
Good, that is what I meant with making request and response associated to each other.
It is less a matter of having a single thread but exclusively using the single thread for one purpose (looping) so it can't do anything else (like processing events for QProcess).
Basically you've deadlocked yourself.
Definitely. A GUI should never assume that I/O is instantaneous, especially nothing that will require communication with a different system (via network, cable, etc).
It is very rare that such communication has deterministic and guaranteed response times that would make blocking the UI a viable approach.
Luckily most I/O in Qt is handled asynchronously so you don't have to do anything special (e.g. threads) to make it non-blocking.
No, as application output is very application specific, i.e. how the application separates output of different responses, etc.
The window just needs to know which StockQuote object to work with.
In the QNAM example it would just need to know which QNAM to work with.
Since you can associate responses to requests, you just need to pick the right "reply" handler to pass it to, like QNAM knows which QNetworkReply to pass incoming response data to.
Each window only knows its reply object, so it won't be confused by other windows' data.
Cheers,
_
Bookmarks