From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id B7B9F3858031 for ; Sun, 16 May 2021 21:47:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B7B9F3858031 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from reform (unknown [172.31.132.202]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 84402302BBED; Sun, 16 May 2021 23:47:26 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id D32FF2E82D24; Sun, 16 May 2021 23:47:25 +0200 (CEST) Date: Sun, 16 May 2021 23:47:25 +0200 From: Mark Wielaard To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org Subject: Re: PR27859 PATCH: correct 404-latch in connection reuse Message-ID: References: <20210514225117.GA23897@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210514225117.GA23897@redhat.com> X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 May 2021 21:47:29 -0000 Hi Frank, On Fri, May 14, 2021 at 06:51:17PM -0400, Frank Ch. Eigler via Elfutils-devel wrote: > (I'll deploy this fix to one of the public servers to confirm it there.) Thanks. If that looks good, please commit. > Author: Frank Ch. Eigler > Date: Fri May 14 18:37:30 2021 -0400 > > PR27859: correct 404-latch bug in debuginfod client reuse > > PR27701 implemented curl handle reuse in debuginfod_client objects, > but with an unexpected bug. Server responses returning an error > "latched" because the curl_easy handles for error cases weren't all > systematically removed from the curl multi handle. This prevented > their proper re-addition the next time. > > This version of the code simplfies matters by making only the curl > curl_multi handle long-lived. This turns out to be enough, because it > can maintain a pool of long-lived http/https connections and related > data, and lend them out to short-lived curl_easy handles. This mode > handles errors or hung downloads even better, because the easy handles > don't undergo complex state transitions between reuse. > > A new test case confirms this correction via the federating debuginfod > instance (cleaning caches between subtests to make sure http* is being > used and reused). It is nice that the multi code works that way, it makes things a bit simpler and less state to keep around for the debuginfod_client handle. The changes look good to me. And the new testcase passes here. Cheers, Mark