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 4E6E23858C83 for ; Fri, 22 Apr 2022 22:14:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4E6E23858C83 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 reform (deer0x0a.wildebeest.org [172.31.17.140]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 6179730003C8; Sat, 23 Apr 2022 00:14:37 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id 21F092E8226E; Sat, 23 Apr 2022 00:14:37 +0200 (CEST) Date: Sat, 23 Apr 2022 00:14:36 +0200 From: Mark Wielaard To: libcurl development Cc: elfutils-devel@sourceware.org Subject: Re: Using libcurl in another library, when/if to call curl_global_init? Message-ID: References: <1ea188affb14c7b55ec1d54fe95627d83e730bb4.camel@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP 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: Fri, 22 Apr 2022 22:14:40 -0000 Hi, On Thu, Mar 31, 2022 at 03:19:51PM +0200, Mark Wielaard via curl-library wrote: > On Thu, Mar 31, 2022 at 04:00:16PM +0300, Catalin Raceanu via curl-library wrote: > > On 31-Mar-22 15:04, Mark Wielaard wrote: > > > whether there is a thread-safe way to call > > > curl_global_init at a later time (to get rid of the library constructor > > > init function). > > > > I believe that this is an exact fit for C==11's std::call_once(). Boost also > > has an equivalent, that most likely predates the other, in case older c++ > > standard is used. > > Thanks. Our library is pure C, but we can probably rely on > pthread_once if it is allowable to call curl_global_init at a later > time when multiple threads are already running. The reason we aren't > doing that now is because the curl_global_init documentation > explicitly states "You must not call it when any other thread in the > program is running". But maybe we are interpreting the documentation > too strictly? Since it does seem we were interpreting the documentation a bit too strictly I did propose a patch for elfutils that does lazy initialization using pthread_once. https://sourceware.org/pipermail/elfutils-devel/2022q2/004934.html This makes sure we don't race against ourselves. And for programs using our library we can assume they will call curl_global_init before creating a multi-threaded environment and calling our own handle initialization functions. It would still be great if curl_global_init itself could be made thread-safe to call. Thanks, Mark