public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Mark Wielaard <mark@klomp.org>
Cc: lilydjwg <lilydjwg@gmail.com>, elfutils-devel@sourceware.org
Subject: PR30809, was Re: [PATCH v2 2/2] debuginfod-client.c: Fix x-debuginfod-size counts differently than CURLINFO_SIZE_DOWNLOAD_T
Date: Tue, 29 Aug 2023 14:33:07 -0400	[thread overview]
Message-ID: <20230829183307.GE24480@redhat.com> (raw)
In-Reply-To: <aefed5037698157e9bd593d8743df4610db9fccf.camel@klomp.org>

Hi -

> What is the status of this patch/discussion?

Ummmm forgot about it.  But that's OK, filed PR30809, and wrote &
tested this little patch:

commit 3ef3fab0d64c89a52dd6e2ce0d01dd5e713d7b5a
Author: Frank Ch. Eigler <fche@redhat.com>
Date:   Tue Aug 29 14:08:04 2023 -0400

    PR30809: improve debuginfod client progress-callback parameters
    
    * debuginfod-client.c (debuginfod_query_server): Use fstat(3)
      of the file handle being downloaded into as the preferred
      source of download progress.
    
    Tested by hand, as the testsuite doesn't have enough machinery to
    simulate compressed vs. uncompressed service.  Hand testing with
    (unmodified) fedora-38 gdb and debuginfod-find shows dramatically
    improved progress displays: all have quantitative figures when
    fetching from real (unmodified) upstream servers.
    
    Signed-off-by: Frank Ch. Eigler <fche@redhat.com>

diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index d92d8d62c982..6882cb190d3c 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -1533,6 +1533,20 @@ debuginfod_query_server (debuginfod_client *c,
           long pa = loops; /* default param for progress callback */
           if (target_handle) /* we've committed to a server; report its download progress */
             {
+              /* PR30809: Check actual size of cached file.  This same
+                 fd is shared by all the multi-curl handles (but only
+                 one will end up writing to it).  Another way could be
+                 to tabulate totals in debuginfod_write_callback(). */
+              struct stat cached;
+              int statrc = fstat(fd, &cached);
+              if (statrc == 0)
+                pa = (long) cached.st_size;
+              else
+                {
+                  /* Otherwise, query libcurl for its tabulated total.
+                     However, that counts http body length, not
+                     decoded/decompressed content length, so does not
+                     measure quite the same thing as dl. */
                   CURLcode curl_res;
 #if CURL_AT_LEAST_VERSION(7, 55, 0)
                   curl_off_t dl;
@@ -1549,7 +1563,7 @@ debuginfod_query_server (debuginfod_client *c,
                   if (curl_res == 0)
                     pa = (dl >= (double)(LONG_MAX+1UL) ? LONG_MAX : (long)dl);
 #endif
-
+                }
             }
 
           if ((*c->progressfn) (c, pa, dl_size == -1 ? 0 : dl_size))


  reply	other threads:[~2023-08-29 18:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-29  4:51 [PATCH] debuginfod-client.c: Fix download size not correctly fallbacks to x-debuginfod-size header lilydjwg
2023-03-29 12:28 ` Frank Ch. Eigler
2023-03-29 14:57   ` lilydjwg
2023-03-29 15:02     ` [PATCH v2 1/2] " lilydjwg
2023-03-29 15:02       ` [PATCH v2 2/2] debuginfod-client.c: Fix x-debuginfod-size counts differently than CURLINFO_SIZE_DOWNLOAD_T lilydjwg
2023-03-29 19:14         ` Frank Ch. Eigler
2023-03-30  3:41           ` lilydjwg
2023-03-30 17:24             ` Frank Ch. Eigler
2023-03-31  4:50               ` lilydjwg
2023-08-29 13:17                 ` Mark Wielaard
2023-08-29 18:33                   ` Frank Ch. Eigler [this message]
2023-08-29 19:26                     ` PR30809, was " Mark Wielaard
2023-03-29 20:49       ` [PATCH v2 1/2] debuginfod-client.c: Fix download size not correctly fallbacks to x-debuginfod-size header Frank Ch. Eigler
2023-03-29 15:05     ` [PATCH] " lilydjwg

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=20230829183307.GE24480@redhat.com \
    --to=fche@redhat.com \
    --cc=elfutils-devel@sourceware.org \
    --cc=lilydjwg@gmail.com \
    --cc=mark@klomp.org \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).