PATCH: PR27701: debuginfod clients with long-lived curl handles

[Frank Ch. Eigler]

Hi -

> This is really nice. We should indeed also reuse a debuginfod_client
> handle in libdwfl for a Dwfl or Dwfl_Module when we figure
> out/document the multi-thread use case. [...]


> > -Before a lookup function is initiated, a client application may
> > -add HTTP request headers to future downloads.
> > +Before each lookup function is initiated, a client application may
> > +add HTTP request headers.  These are reset after each lookup function.
> 
> Why do we need to reset the headers? Is that because we don't have
> debuginfod_remove_http_header? Should we maybe add that (or a
> reset_http_header)?

That would be possible too, probably, depending on how much state curl
is willing to keep.  Normal clients wouldn't do any of this.  It's
important for debuginfod's federated use case (proxying), which always
resets between calls anyway.


> > @@ -90,10 +113,6 @@ wait_ready()
> >    done;
> >  
> >    if [ $timeout -eq 0 ]; then
> > -      echo "metric $what never changed to $value on port $port"
> 
> I think we want to keep this message ^ it helps with knowing which
> exact metric timed out.

OK.


- FChE