From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id DA5593858C50 for ; Tue, 5 Apr 2022 16:19:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DA5593858C50 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 20F99301BC17; Tue, 5 Apr 2022 18:19:16 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id D1757413CD0E; Tue, 5 Apr 2022 18:19:13 +0200 (CEST) Message-ID: Subject: Re: Using libcurl in another library, when/if to call curl_global_init? From: Mark Wielaard To: Daniel Stenberg , curl-library@lists.haxx.se Cc: elfutils-devel@sourceware.org Date: Tue, 05 Apr 2022 18:19:13 +0200 In-Reply-To: References: <1ea188affb14c7b55ec1d54fe95627d83e730bb4.camel@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Tue, 05 Apr 2022 16:19:20 -0000 On Tue, 2022-04-05 at 17:36 +0200, Daniel Stenberg wrote: > On Thu, 31 Mar 2022, Mark Wielaard via curl-library wrote: >=20 > > But we are struggling a bit with how to safely/correctly initialize > > libcurl. >=20 > Are you struggling to meet the requirement as per the documentation > or are you seeing actual runtime issues? Struggling with the requirements as per the documentation "You must not call it [curl_global_init] when any other thread in the program is running". Especially combined with having users who would not like to pay the cost of initializing libcurl (in FIPS mode) when the program isn't explicitly using the remote resource functionality of our library (but is still linked to it). We are a library that is (sometimes) dlopened, so we cannot guarantee that when we call curl_global_init no other thread in the program is running. But we try to mitigate that by having a __attribute__((constructor)) ctor that just does curl_global_init(CURL_GLOBAL_DEFAULT); Which in most cases (especially if we aren't dlopened) should make sure we run before the program has any chance to start any new threads. But that of course also makes sure that we (or the program linking to our library) always pays the cost for calling curl_global_init, which at least in FIPS mode does some non-trivial checks. So we are wondering if instead we could do lazy initialization just before we know we will actually need to load a remote resource. We could wrap such an initialization inside a pthread_once, so at least with multiple threads we don't race against ourselves given that curl_global_init itself is not thread-safe (it uses a unguarded initialized int). But Florian just pointed out that we would still race against other uses of libcurl in the program, in case they also didn't call curl_global_init before starting any other threads. Cheers, Mark