Re: [PATCH] reduce progress updates in background

From: Nicolas Pitre <nico@fluxnic.net>
Date: Apr 13, 2015, 15:01 UTC
Message-ID: <alpine.LFD.2.11.1504131052090.5619@knanqh.ubzr>
In-Reply-To: <20150413144039.GD23475@mewburn.net>

On Tue, 14 Apr 2015, Luke Mewburn wrote:

Show 10 quoted lines

> On Mon, Apr 13, 2015 at 10:11:09AM -0400, Nicolas Pitre wrote:
>   | What if you suspend the task and push it into the background? Would be 
>   | nice to inhibit progress display in that case, and resume it if the task 
>   | returns to the foreground.
> 
> That's what happens; the suppression only occurs if the process is
> currently background.  If I start a long-running operation (such as "git
> fsck"), the progress is displayed. I then suspend & background, and the
> progress is suppressed.  If I resume the process in the foreground, the
> progress starts to display again at the appropriate point.

I agree. I was just comenting on your suggestion about caching the in_progress_fd() result which would prevent that.

Show 7 quoted lines

> In the proposed patch, the stop_progress display for a given progress
> (i.e. the one that ends in ", done.") is displayed even if in the
> background so that there's some indication of progress. E.g.
>   Checking object directories: 100% (256/256), done.
>   Checking objects: 100% (184664/184664), done.
>   Checking connectivity: 184667, done.
> This is the test 'if (is_foreground || done)'.

Yes.  And I think this is nice.

Show 8 quoted lines

>   | Also the display() function may be called quite a lot without 
>   | necessarily resulting in a display output. Therefore I'd suggest adding 
>   | in_progress_fd() to the if condition right before the printf() instead.
> 
> That's an easy enough change to make (although I speculate that the
> testing of the foreground status is not that big a performance issue,
> especially compared the the existing performance "overhead" of printing
> the progress to stderr then forcing a flush :)

Sure. But what I'm saying is that progress() may be called a thousand times and only one or two of those calls will result in an actual print-out. So it is best to test the foreground status only at that point.

> Should I submit a revised patch with
> (1) call in_progress_fd() just before the fprintf() as requested, and
> (2) suppress all display output including the "done" call.
> ?

I'd suggest (1) but not (2).

Nicolas