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 --]
next prev parent 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).