On Sat, Feb 1, 2014 at 8:29 PM, Oskari Saarenmaa <os@ohmu.fi> wrote: > 31.01.2014 10:59, Sawada Masahiko kirjoitti: >
> I think the idea in the new progress_report() call (with force == true) is > to make sure that there is at least one progress_report call that actually > writes the progress report. Otherwise the final report may go missing if it > gets suppressed by the time-based check. The force argument as used in the > new call skips that check. >
I understood.
I have two concerns as follows. - I think that there is possible that progress_report() is called frequently ( less than 1 second). That is, progress_report() is called with force == true after progress_report was called with force == false and execute this function. - progress_report() is called even if -P option is disabled. I'm concerned about that is cause of performance degradation.
I looked over the latest version, and the only real problem I see here is your second point, which is the calling with -P not specified. I doubt it's going to be much, but in theory I guess the call to time(NULL) many times could have an effect. I've fixed that by just moving it to after a check for showprogress.
As for the first one - I believe that's the point. progress_report should be called with force==true after it was called with it false, that's the intended design.
I've applied the patch, with that minor adjustment and an added comment.