QProcess signal out of order ?

[DalePennington]

Folks,
We have an application using QProcess to run an external command, in this case an untar command. We then process the output to provide status info by having a slot connected to readyReadStandardOutput that calls readAllStandardOutput and processes the data. We also have a slot connected to finished to detect when the command is complete. So we expected to start the process, get a series of readyReadStandardOutput signals to process and then the finished signal.

This works fine on our development machine. But when we moved the app to a more powerful machine, we got some readyReadStandardOutputSignals, but then the finished signal followed by some more readyReadStandardOutput signals, which blew our initial assumptions.

Is this expected behavior ? If so, why ? I might have expected one more (say we were processing one read while the app finished, and have one more readyReadStandardOutput after the finished signal to have the leftover data, but not multiples of them.

Thanks,
Dale Pennington

[jeremy_k]

@DalePennington said in QProcess signal out of order ?:

I might have expected one more (say we were processing one read while the app finished, and have one more readyReadStandardOutput after the finished signal to have the leftover data, but not multiples of them.

What version of Qt, and what platform is involved?

Is there a nested event loop, or a connection to a slot in another thread?

[DalePennington]

This is Qt5 (5.12.5 in particular) on Red Hat Linux 8.4. We are not using any QThreads in this application, so its the signal GUI thread with the default event processing.

Dale

[JonB]

@DalePennington
@jeremy_k may know more about the internals of QProcess than I, but I would not expect to guarantee that all output would be received before the finished signal.

Assuming finished corresponds to to the subprocess exiting, it is quite possible to receive final output after that. It depends on (OS) buffering of output pipes, and when that occurs/they get flushed relative to subprocess exit.

You might look at Qt's internal implementation of its blocking subprocess calls, I forget what they are but something like QProcess::exec() et al. They return when subprocess exits and you can still read output from process.

As for

one more readyReadStandardOutput after the finished signal to have the leftover data, but not multiples of them.

I would not read any guarantees into how often readReads signals are raised relative to input flow/"left over data".

I admit, thinking about it, this raises an interesting question as to how you are supposed to know for sure when no more output can be received versus program exit time. Usually the pipe would be closed when end of incoming data is received, rather than depending on exit instant.

[jeremy_k]

How about the nested event loop question? I ask because:

we were processing one read while the app finished

This implies notification that the process has exited. Otherwise, the process is a metaphorical cat in a box. If that notification happens while executing a slot connected to readyReadStandardOutput(), additional emissions of the readyRead signal won't have had a chance to fire.

[DalePennington]

Actually, I expected that one more signal would occur if the readyReadStandardOutput was processing while the process finished. The odd thing was there was a second readyReadStandardOutput signal happening. Although I have checked with the guy doing the actual work, and the second one always returns an empty string when readAllStandardOutput is called.