The monitor is stopped as soon as the target process finishes - which means that the very last reading emitted will only contain information from during the run of the target.
If it were done the other way around then we'd have to poll for the termination of the forked target process. Either the poll duration would have to be really small or the monitor would contain readings for some time after the end of the target.
This isn't so bad when running with an interval of 1 second... but for an interval of 1 minute (or longer) it can start to give odd readings.
To be honest, I'm thinking of removing the very final reading anyway. Or, at least documenting that the final reading may be slightly misleading.
Ah. I was mucking around in the subprocess module at one point, and IIRC it already forks the subprocess that it launches, even if you're just doing something like subprocess.call().
If it were done the other way around then we'd have to poll for the termination of the forked target process. Either the poll duration would have to be really small or the monitor would contain readings for some time after the end of the target.
This isn't so bad when running with an interval of 1 second... but for an interval of 1 minute (or longer) it can start to give odd readings.
To be honest, I'm thinking of removing the very final reading anyway. Or, at least documenting that the final reading may be slightly misleading.