git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luke Mewburn <luke@mewburn.net>
To: Nicolas Pitre <nico@fluxnic.net>, git@vger.kernel.org
Cc: Luke Mewburn <luke@mewburn.net>
Subject: Re: [PATCH] reduce progress updates in background
Date: Tue, 14 Apr 2015 00:40:39 +1000	[thread overview]
Message-ID: <20150413144039.GD23475@mewburn.net> (raw)
In-Reply-To: <alpine.LFD.2.11.1504130954420.5619@knanqh.ubzr>

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

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.

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)'.

I'm not 100% happy with my choice here, and the simpler behaviour
of "suppress all background progress output" can be achieved by
removing '|| done' from those two tests.

That still doesn't suppress _all_ output whilst in the background.
In order to do that, a larger refactor of various warning methods
would be required. I would argue that's a separate orthoganal fix.


  | 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 :)


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.
?


regards,
Luke.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2015-04-13 14:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-13 13:48 [PATCH] reduce progress updates in background Luke Mewburn
2015-04-13 14:11 ` Nicolas Pitre
2015-04-13 14:40   ` Luke Mewburn [this message]
2015-04-13 15:01     ` Nicolas Pitre
2015-04-14 11:03       ` [PATCH v2] " Luke Mewburn
2015-04-14 15:16         ` Nicolas Pitre
2015-04-15 18:29         ` [PATCH] compat/mingw: stubs for getpgid() and tcgetpgrp() Johannes Sixt
2015-04-15 18:48           ` Junio C Hamano
2015-04-15 20:34             ` Johannes Sixt
2015-04-16 12:48             ` Johannes Schindelin
2015-04-16 15:00               ` Junio C Hamano
2015-04-15 19:43           ` Erik Faye-Lund
2015-04-16 12:44             ` [msysGit] " Johannes Schindelin
2015-04-23 19:25               ` rupert thurner
2015-04-24  3:03                 ` rupert thurner
2015-04-24  6:25                 ` [msysGit] " Johannes Schindelin
2015-04-17  1:25           ` Luke Mewburn
2015-04-14 11:08       ` [PATCH] reduce progress updates in background Luke Mewburn
2015-04-14  3:12 ` brian m. carlson
2015-04-14  8:47   ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150413144039.GD23475@mewburn.net \
    --to=luke@mewburn.net \
    --cc=git@vger.kernel.org \
    --cc=nico@fluxnic.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).