rfc/patch: debuginfod client $DEBUGINFOD_PROGRESS env var

[Mark Wielaard]

Hi Frank,

On Sun, Dec 22, 2019 at 08:38:59PM -0500, Frank Ch. Eigler wrote:
> Yeah, a connection timeout per se is probably not really worth having.
> A URL having unreasolvable hosts will fail immediately.  A reachable
> http server that is fairly busy will connect, just take time.  The
> only common cases a connection timeout would catch is a running http
> server that is so overloaded that it can't even service its accept(4)
> backlog, or a nonexistent one that has been tarpit/firewalled.  A
> minimal progress timeout can subsume cases too.
> 
> OTOH, it's worth noting that these requests only take this kind of
> time if they are being seriously serviced, i.e., "they are worth it".
> Error cases fail relatively quickly.  It's the success cases - and
> these huge vmlinux files - that take time.  And once the data starts
> flowing - at all - the rest will follow as rapidly as the network
> allows.
> 
> That suggests one timeout could be sufficient - the progress timeout
> you the one you found - just not too short and not too fast.

How about the attached (untested) patch?

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-debuginfod-Use-DEBUGINFOD_TIMEOUT-as-seconds-to-get-.patch
Type: text/x-diff
Size: 7888 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/elfutils-devel/attachments/20200102/03780bce/attachment.bin>