On Mon, Feb 3, 2014 at 4:14 AM, Sawada Masahiko <sawada.m...@gmail.com>wrote:

> On Sat, Feb 1, 2014 at 8:29 PM, Oskari Saarenmaa <o...@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.

 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Reply via email to